The Requirements Workflow - Software Engineering - Lecture Notes, Study notes of Software Engineering

Download The Requirements Workflow - Software Engineering - Lecture Notes and more Study notes Software Engineering in PDF only on Docsity!

Topics on Software Engineering

The Requirements Workflow

Outline

 The requirements workflow

 Metamodel for software requirements

 Requirements workflow details

 The importance of requirements

 Defining requirements

.The Requirements Workflow

 The purpose of the requirements workflow is to reach an agreement on what the system should do, expressed in a way accessible to the users of the system  Requirements engineering involves: elicitation, negotiation, conflict resolution, prioritization, documentation, and maintenance of requirements  Various stakeholders are involved in establishing the set of requirements for the system  UML uses cases describe functional requirements, but non-functional requirements need different description

Metamodel for Software Requirements Arlow & Neustadt’s approach for requirements engineering is shown in Fig. 3.3 [Arlow 2002]. Details can be found in Section 3.

.Requirements Workflow Detail

Arlow and Neustadt extend slightly the UP requirements workflow with the addition of new tasks: find functional requirements, find non- functional requirements, prioritize requirements, & trace requirements to use cases. As such, non-functional requirements can be addressed as well, along with the traditional UP/UML treatment of functional requirements via use cases. Fig. 3.5 [Arlow & Neustadt 2005]

The Importance of Requirements

 Requirements engineering is about establishing what

the stakeholders need from the system  Requirements engineering encompasses elicitation, negotiation, conflict resolution, prioritization, documentation, and maintenance of requirements  Poor requirements engineering is the major cause of software project failure  The second major cause of software project failure is lack of user participation

.Defining Requirements...

 The SRS ( Systems Requirements Specification) is the

document that contains the set of requirements expected to be satisfied by the system, both functional and non-functional  There are many ways to write an SRS (“company dependent” ways)  The SRS provides the input for the analysis and design phases of the development process  The bottom line regarding the SRS is: “does it help me to understand what the system should do or not?”

..Defining Requirements..

 Simple format recommended for well-formed requirements: The shall  Examples of functional requirements (what the system should do): 1 The ATM shall check the validity of the ATM card inserted. 2 The ATM shall validate the PIN number entered by the client. 3 The ATM shall dispense no more than $500 against any ATM card in any 24-hour period  Examples of non-functional requirements (constraints on or properties of the system): 1 The ATM shall be written in C++. 2 The ATM shall validate the PIN in three seconds or less.

….Defining Requirements

 Requirements may have attributes, e.g.

 Must have  Should have  Could have  Want to have [the MoSCoW system]

 Requirement attributes in RUP:

 Status (proposed, approved, rejected, incorporated)  Benefit (critical, important, useful)  Effort (measured in person*day or function points)  Risk (high, medium, low)  Stability (high, medium, low)  TargetRelease (product version when implemented)

Finding Requirements..

 Requirements come from the context of the system:

 Direct users  Other stakeholders (e.g., managers, maintainers, installers)  Other systems that interact with the system  Hardware devices attached to the system  Legal and regulatory constraints  Technical constraints  Business goals

..Finding Requirements

 Interviews:  Don’t imagine a solution  Don’t mind read  Ask context-free questions  Listen  Have patience!  Questionnaire: they can supplement interviews.  Good at getting answers to closed questions  Requirements workshop  Participants: facilitator, requirements engineer, stakeholders, domain experts  Procedure: 1 Brainstorm (accept all ideas) 2 Identify key requirements 3 Iterate over, refine, and prioritize requirements