Requirements Engineering

1
Requirements Engineering

• How do we keep straight what we are
• supposed to be building?

2
Starter Questions

• What is a "requirement"?
• How do we determine the requirements?
• Why is requirements engineering difficult?

3
Why good Specs are Essential

• It is VERY expensive to fix problems late in the
  process. It is very cheap to rewrite or clarify
  a written spec.
• What costs 1 to fix at ReqGathering
• 5 in the design stage
• 10 in the coding stage
• 20 in the unit testing phase
• 200 after delivery

4
Types of Requirements

• Functional
• ex - it must email the sales manager when an
  inventory item is "low"
• Non-Functional
• ex - it must require less than one hour to run
  report 5
• Explicit
• ex required features
• Implied
• ex software quality
• Forgotten
• ex exists in current process
• Unimagined

5
Requirements of Requirements

• Clear
• Measurable
• Feasible
• Necessary
• Prioritized
• Concise

6
Ambiguousness example one

• The control total is taken from the last record.
• The total is taken from the record at the end of
  the file.
• The total is taken from the latest record.
• The total is taken from the previous record.

IEEE 830-1984
7
Ambiguousness example two

• All customers have the same control field.
• All customers have the same value in their
  control field.
• All control fields have the same format.
• One control field is issued for all customers.

IEEE 830-1984
8
Why Req Eng is Difficult
9
Requirements Engineering Tasks

• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Management
• Software Engineering A Practitioners Approach
  by Roger Pressman

10
Inception

• Project starts due to a business decision
• Software Engineer Asks
• Why do you want this
• What is the basic problem
• Who wants a solution
• who wants this
• who will use this
• Nature of solution
• economic benefit of success?

11
Requirements Engineering Tasks

• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Management

12
Elicitation via InterviewsDifficulties

• Ill-defined project scope
• Unnecessary details that confuse
• Not sure what they need
• Poor understanding of capabilities
• Omitting the obvious
• Requirements that conflict with other peoples
  requirements
• Requirements Change!!!

13
Elicitation via InterviewsRecommendations

• The list of involved stakeholders must be broad
• include end-users, managers, etc
• include the software developers
• Use agendas that cover the important points yet
  encourage flow of ideas
• Ahead of time, the participants should build a
  partial list of the functions, performance
  criteria, environment factors,
• Start with scope and context, move to functions
• Use visuals such as wall-stickers, flip-charts,

14
Elicitation via Use Cases
http//www.evanetics.com/Articles/ar_usecases/uc_v
alueofucd.htm
15
Elicitation via QFD

• Since 1966, Quality Function Deployment (QFD) has
  been used world wide in nearly every industry and
  sector to
• Prioritize spoken and unspoken customer wows,
  wants, and needs
• Translate these needs into actions and designs
  such as technical characteristics and
  specifications and
• Build and deliver a quality product or service by
  focusing various business functions toward
  achieving a common goal and customer
  satisfaction.
• www.qfdi.org
• QFD uses interviews, surveys, and data (problem
  reports) to build a table of requirements called
  the Customer Voice Table.
• Functional Deployment value of each function
• Information Deployment identify the input and
  output
• Task Deployment examine system behavior
• Value Analysis prioritize the requirements

16
Requirements Engineering Tasks

• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Management

17
Elaboration

• Goal is to create a model that defines
• information
• functions
• Models could be
• ER Diagrams
• Use Cases
• Data Flow Diagrams
• all of the above

http//www.camsp.com/cornerstone/assets/images/res
ources/when_use_maps_sm.png
18
System Modeling

• Function Information Flow Model
• what we will do with the data
• Data Model
• structure of the information
• Behavior Model
• how we interact with the system

19
Data Modeling

• Data Objects, Attributes, Relationships
• Formatted as Lists or Tables
• Entity Relationship Diagrams

20
Behavior Modeling

• State Transition Diagram

done
start
file name
1
2
3
save msg
read msg
send
compose
4
21
Requirements Engineering Tasks

• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Management

22
Negotiation

• Goal is to resolve requirements that are
• Conflicting
• Costly
• Unrealistic
• Identify the subsystems stakeholders
• Determine their win conditions
• Negotiate their win conditions into win-win
  conditions for everyone

23
Requirements Engineering Tasks

• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Management

24
Technically Speaking,"requirement" ?
"specification"

• Requirement understanding between customer and
  supplier
• Specification what the software must do
• Requirements that are not in the SRS
• Costs
• Delivery dates
• Acceptance procedures
• etc

25
IEEE 830

• Characteristics of a Good SRS
• Unambiguous
• Complete
• Verifiable
• Consistent
• Modifiable
• Traceable
• Usable during the Operation and Maintenance Phase

26
IEEE 830

• Role of SRS
• The SRS must correctly define all of the
  software requirements, but no more.
• The SRS should not describe design,
  verification, or project management details,
  except for required design constraints.

27
SRS Table of Contents

1. Introduction
2. Purpose
3. Scope
4. Definitions
5. References
6. Overview
7. General Description
8. Product Perspective
9. Product Functions
10. User Characteristics
11. General Constraints
12. Assumptions and Dependencies
13. Specific Requirements

IEEE 830-1984
28
3. Specific Requirements 3.1 Functional
Requirements 3.1.1 Func Req 1
3.1.1.1 Introduction 3.1.1.2
Inputs 3.1.1.3 Processing
3.1.1.4 Outputs 3.1.2 Func Req 2
3.2 External Interface
Requirements 3.2.1 User Interface
3.2.2 Hardware Interfaces 3.2.3
Software Interfaces 3.2.4 Communication
Interfaces 3.3 Performance Requirements
3.4 Design Constraints 3.4.1 Standards
Compliance 3.4.2 Hardware Limitations
3.5 Attributes 3.5.1 Security
3.5.2 Maintainability 3.6 Other
Requirements 3.6.1 Database
IEEE 830-1984
29
Non-830-Style Requirements

• User stories encourage the team to defer
  collecting details. An initial place-holding
  goal-level story ("A Recruiter can post a new job
  opening") can be written and then replaced with
  more detailed stories once it becomes important
  to have the details. This technique makes user
  stories perfect for time-constrained projects. A
  team can very quickly write a few dozen stories
  to give them an overall feel for the system. They
  can then plunge into the details on a few of the
  stories and can be coding much sooner than a team
  that feels compelled to complete an IEEE
  830style software requirements specification.

Quote from "Advantages of User Stories for
Requirements" By Mike Cohn http//www.awprofession
al.com/articles/article.asp?p342885seqNum3
30
Other Specification Techniques

• Use Cases
• Formal Specification Languages
• e.g. Petri Nets

http//www.cs.indiana.edu/classes/p465/Lect/Images
/petri-img-10.jpg
31
Requirements Engineering Tasks

• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Management

32
Next Classes

• Risk Analysis and Management
• Metrics
• Managing the Testing Process