requirements engineering how do we keep straight what we are supposed to be building?
Post on 28-Dec-2015
213 Views
Preview:
TRANSCRIPT
Requirements EngineeringRequirements Engineering
How do we keep straight what we are How do we keep straight what we are
supposed to be building?supposed to be building?
Starter QuestionsStarter Questions
What is a "requirement"?
How do we determine the requirements?
Why is requirements engineering difficult?
2
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
3
Types of RequirementsTypes 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 4
Requirements of RequirementsRequirements of Requirements
Clear
Measurable
Feasible
Necessary
Prioritized
Concise
5
Ambiguousness – example one
The control total is taken from the last record.
1. The total is taken from the record at the end of the file.
2. The total is taken from the latest record.
3. The total is taken from the previous record.
IEEE 830-1984
Ambiguousness – example two
All customers have the same control field.
1. All customers have the same value in their control field.
2. All control fields have the same format.
3. One control field is issued for all customers.
IEEE 830-1984
Requirements Engineering TasksRequirements Engineering Tasks
1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Management
Software Engineering: A Practitioner’s Approach by Roger Pressman9
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?
10
Requirements Engineering TasksRequirements Engineering Tasks
1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Management
11/32
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 people’s requirements
Requirements Change!!!12
Elicitation via InterviewsRecommendations
1. The list of involved stakeholders must be broad include end-users, managers, etc include the software developers
2. Use agendas that cover the important points yet encourage flow of ideas
3. Ahead of time, the participants should build a partial list of the functions, performance criteria, environment factors, …
4. Start with scope and context, move to functions
5. Use visuals such as wall-stickers, flip-charts, …
13
Elicitation via QFDSince 1966, Quality Function Deployment (QFD) has been used world wide
in nearly every industry and sector to: 1. Prioritize spoken and unspoken customer wows, wants, and needs; 2. Translate these needs into actions and designs such as technical
characteristics and specifications; and 3. 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
15
Requirements Engineering TasksRequirements Engineering Tasks
1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Management
16/32
Elaboration
Goal is to create a modelmodel that defines:1. information2. functions
Models could be ER Diagrams Use Cases Data Flow Diagrams all of the above
htt
p:/
/ww
w.c
am
sp.c
om
/corn
ers
tone/a
ssets
/im
ag
es/
reso
urc
es/
when_u
se_m
ap
s_sm
.png
17
System ModelingSystem 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
Data Modeling
Data Objects, Attributes, Relationships Formatted as Lists or Tables
Entity Relationship Diagrams
securitysystem
sensor
monitors
enables/disables
tests
programsis programmed by
Requirements Engineering TasksRequirements Engineering Tasks
1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Management
21/32
Negotiation
Goal is to resolve requirements that are Conflicting Costly Unrealistic
1. Identify the subsystem’s stakeholders
2. Determine their win conditions
3. Negotiate their win conditions into win-win conditions for everyone
22
Requirements Engineering TasksRequirements Engineering Tasks
1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Management
23/32
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
24
IEEE 830
Characteristics of a Good SRS
1. Unambiguous
2. Complete
3. Verifiable
4. Consistent
5. Modifiable
6. Traceable
7. Usable during the Operation and Maintenance Phase
25
IEEE 830
Role of SRS1. “The SRS must correctly define all
of the software requirements, but no more.”
2. “The SRS should not describe design, verification, or project management details, except for required design constraints.”
26
SRS Table of Contents
1. Introduction1. Purpose2. Scope3. Definitions4. References5. Overview
2. General Description1. Product Perspective2. Product Functions3. User Characteristics4. General Constraints5. Assumptions and Dependencies
3. Specific RequirementsIEEE 830-1984
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
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 830–style software requirements specification.
Quote from "Advantages of User Stories for Requirements"By Mike Cohn
http://www.awprofessional.com/articles/article.asp?p=342885&seqNum=3
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
Requirements Engineering TasksRequirements Engineering Tasks
1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Management
31
top related