11

CS 426Senior Projects

Chapter 3: The Requirements Workflow

[Arlow & Neustadt, 2005]

February 10, 2009

22

OutlineOutline

The requirements workflowMetamodel for software requirements

Requirements workflow detailsThe importance of requirementsDefining 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 workflow

Fig. 3.4 [Arlow & Neustadt 2005]

77

.Requirements Workflow .Requirements Workflow DetailDetail

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]

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 a 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 2 The ATM shall validate the PIN number entered by the client.client.

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.. “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 Distortion Generalization

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

1313

.…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

1414

……..Defining Requirements..Defining Requirements Requirements may have attributes, e.g.

Must haveMust have Should haveShould have Could haveCould have Want to have [Want to have [MoSCoWMoSCoW system] system]

Requirement attributes in RUP:Requirement attributes 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 Effort (measured in person*day or function points)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)