CS 691z 791z Topics on Software Engineering

1
CS 691z / 791zTopics on Software Engineering

• Software Requirements
• Based on Chapter 3 The Requirements Workflow
• Arlow Neustadt, 2002
• February 6, 2007

2
Outline

• Requirements
• The requirements workflow
• Metamodel for software requirements
• Requirements workflow details
• The importance of requirements
• Defining requirements

3
The Requirements Workflow.
Fig. 3.2 Arlow Neustadt, 2002 shows that most
of the work in requirements workflow occurs in
Inception and Elaboration phases
4
.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

5
Metamodel for Software Requirements

• Arlow Neustadts approach for requirements
  engineering is shown in
• Fig. 3.3 Arlow 2002. Details can be found in
  Section 3.3

6
Requirements Workflow Detail.

• Specific tasks for UP (Unified Process)
  requirements workflow
• Fig. 3.4 Arlow Neustadt 2002

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

8
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

9
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

10
.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?

11
..Defining Requirements.

• Simple format recommended for well-formed
  requirements
• ltidgt The ltsystemgt shall ltfunctiongt
• 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.
• 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.

12
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