*OutlineThe requirements workflowMetamodel for software requirementsRequirements workflow detailsThe importance of requirementsDefining requirementsChapter 3: The requirements workflow

*The Requirements Workflow

*The Requirements WorkflowThe 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 systemRequirements engineering involves: elicitation, negotiation, conflict resolution, prioritization, documentation, and maintenance of requirementsVarious stakeholders are involved in establishing the set of requirements for the systemUML uses cases describe functional requirements, but non-functional requirements need different description

*Metamodel for Software Requirements

*Requirements Workflow DetailSpecific tasks for UP (Unified Process) requirements workflow

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

*The Importance of RequirementsRequirements engineering is about establishing what the stakeholders need from the systemRequirements engineering encompasses elicitation, negotiation, conflict resolution, prioritization, documentation, and maintenance of requirementsPoor 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.Requirement: a specification of what should be implementedThere are two types of requirements:Functional requirements: describe the desired behaviour of the system Non-functional requirements: specify particular properties of or constraints on the system In theory, the set of requirements should be only about what the system should do, but in practice it is not possible to avoid how aspects of the system

*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 processThe 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.Organizing requirements: a more complex taxonomy can be used when there are many requirements, e.g.Functional requirementsCustomersProductsOrdersSales channelsPaymentsNon-functional requirements: PerformanceCapacityAvailability Compliance with standardsSecurity

*.Defining RequirementsRequirements may have attributes, e.g.Must haveShould haveCould haveWant 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 usersOther stakeholders (e.g., managers, maintainers, installers)Other systems that interact with the systemHardware devices attached to the systemLegal and regulatory constraintsTechnical constraintsBusiness goals

*.Finding RequirementsThe map is not the territory (that is, a model is not the real thing). When modeling, we apply three cognitive filters that simplify our effort [Chomsky, 1975]:Deletion (information is filtered out)Distortion (information is modified)Generalization (information is abstracted into rules, principles, etc)In requirements specification we need to identify the application of the above filters and find challenges for them to recover informationIn particular, universal quantifiers such as all, everyone, always, never, nobody, none should be inspected closely for accuracy

*..Finding RequirementsInterviews:Dont imagine a solution Dont mind readAsk context-free questionsListenHave patience!Questionnaire: they can supplement interviews. Good at getting answers to closed questions Requirements workshopParticipants: facilitator, requirements engineer, stakeholders, domain expertsProcedure: 1 Brainstorm (accept all ideas) 2 Identify key requirements 3 Iterate over, refine, and prioritize requirementsEnd of chapter

***************