2018 Neustadt International Prize for Literature Edwidge ...
1 CS 426 Senior Projects in Computer Science Chapter 3: The Requirements Workflow [Arlow & Neustadt,...
-
Upload
paulina-brittney-carter -
Category
Documents
-
view
216 -
download
0
Transcript of 1 CS 426 Senior Projects in Computer Science Chapter 3: The Requirements Workflow [Arlow & Neustadt,...
11
CS 426Senior Projects in Computer
Science
Chapter 3: The Requirements Workflow
[Arlow & Neustadt, 2005]
February 11, 2014
22
OutlineOutline
The requirements workflow Metamodel for software requirements Requirements workflow details The importance of requirements Defining requirements
33
The Requirements Workflow.The Requirements Workflow. Fig. 3.2 [Arlow & Neustadt 2005] shows that most of the work in requirements workflow occurs in Inception and Elaboration phases
44
.The Requirements .The Requirements WorkflowWorkflow
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
55
Metamodel for Software Metamodel for Software RequirementsRequirements
Arlow & Neustadt’s approach for requirements engineering is shown in
Fig. 3.3 [Arlow 2002]. Details can be found in Section 3.3
66
Requirements Workflow Requirements Workflow Detail.Detail.
Specific tasks for UP (Unified Process) requirements workflowFig. 3.4 [Arlow & Neustadt 2005]
77
.Requirements Workflow Detail.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]
88
The Importance of The Importance of RequirementsRequirements
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
99
Defining Requirements.…Defining Requirements.…
Requirement: “a specification of what should be implemented”
There 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
1010
.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?”
1111
..Defining Requirements....Defining Requirements.. Simple format recommended for well-formed requirements:
<id> The <system> shall <function>
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.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 3 The ATM shall dispense no more than $500 against any ATM card in any 24-hour periodin 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.
1212
……Defining Requirements.Defining Requirements. Organizing requirements: a more complex
taxonomy can be used when there are many requirements, e.g. Functional requirementsFunctional requirements
CustomersCustomersProductsProductsOrdersOrdersSales channelsSales channelsPaymentsPayments
Non-functional requirements: Non-functional requirements: PerformancePerformanceCapacityCapacityAvailability Availability Compliance with standardsCompliance with standardsSecuritySecurity
1313
…….Defining Requirements.Defining Requirements Requirements may have attributes, e.g.
Must haveMust have Should haveShould have Could haveCould have Want to have [the Want to have [the MoSCoWMoSCoW system] system]
Requirement Requirement attributesattributes in RUP: in RUP: Status (proposed, approved, rejected, Status (proposed, approved, rejected,
incorporated)incorporated) Benefit (critical, important, useful)Benefit (critical, important, useful) Effort (measured in person*day or function points)Effort (measured in person*day or function points) Risk (high, medium, low)Risk (high, medium, low) Stability (high, medium, low)Stability (high, medium, low) TargetRelease (product version when TargetRelease (product version when
implemented)implemented)
1414
Finding Requirements..Finding Requirements.. Requirements come from the context of the
system:
Direct usersDirect users Other stakeholders (e.g., managers, maintainers, Other stakeholders (e.g., managers, maintainers,
installers)installers) Other systems that interact with the systemOther systems that interact with the system Hardware devices attached to the systemHardware devices attached to the system Legal and regulatory constraintsLegal and regulatory constraints Technical constraintsTechnical constraints Business goals Business goals
1515
.Finding Requirements.Finding Requirements “The 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 information
In particular, universal quantifiers such as all, everyone, always, never, nobody, none should be inspected closely for accuracy
1616
..Finding Requirements..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