4. 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
5. 5
The Problems with our
Requirements Practices
• We have trouble understanding the requirements that we do
acquire from the customer
• We often record requirements in a disorganized manner
• We spend far too little time verifying what we do record
• We allow change to control us, rather than establishing
mechanisms to control change
• Most importantly, we fail to establish a solid foundation for
the system or software that the user wants built
6.
7. TTyyppeess ooff RReeqquuiirreemmeennttss
• 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 7
10. 10
A Solution: Requirements
Engineering
• Begins during the communication activity and continues into the
modeling activity
• Builds a bridge from the system requirements into software
design and construction
• Allows the requirements engineer to examine
– the context of the software work to be performed
– the specific needs that design and construction must address
– the priorities that guide the order in which work is to be completed
– the information, function, and behavior that will have a profound
impact on the resultant design
11. Requirement Engineering
– RE helps software engineer to better
understand the problem they will work
to solve
– Participant : Software Engineers,
managers, customers and end users
– RE is a software engineering action that
begin during the communication activity
and continues into the modeling activity
12. RE Provides the appropriate mechanism for
• Understanding what the customer want
• Analyzing need
• Assessing feasibility
• Negotiating a reasonable solution
• Specifying a solution unambiguously
• Validating the specification
• Managing the requirement as they are
transformed into an operational system
13. 13
Requirements Engineering
Tasks
• Seven distinct tasks
– Inception
– Elicitation
– Elaboration
– Negotiation
– Specification
– Validation
– Requirements Management
• Some of these tasks may occur in parallel and all are
adapted to the needs of the project
• All strive to define what the customer wants
• All serve to establish a solid foundation for the design and
construction of the software
15. Requirement Engineering Tasks
• Inception—Establish a basic understanding of the problem and
the nature of the solution.
• Elicitation—Draw out the requirements from stakeholders.
• Elaboration—Create an analysis model that represents
information, functional, and behavioral aspects of the
requirements.
• Negotiation—Agree on a deliverable system that is realistic for
developers and customers.
• Specification—Describe the requirements formally or informally.
• Validation—Review the requirement specification for errors,
ambiguities, omissions, and conflicts.
• Requirements management—Manage changing requirements.
16. 16
Inception Task
• During inception, the requirements engineer asks a set of
questions to establish…
– A basic understanding of the problem
– The people who want a solution
– The nature of the solution that is desired
– The effectiveness of preliminary communication and collaboration
between the customer and the developer
• Through these questions, the requirements engineer needs to…
– Identify the stakeholders
– Recognize multiple viewpoints
– Work toward collaboration
– Break the ice and initiate the communication
17. 17
The First Set of Questions
These questions focus on the customer, other stakeholders, the
overall goals, and the benefits
• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful
solution?
• Is there another source for the solution that you need?
18. 18
The Next Set of Questions
These questions enable the requirements engineer to gain a
better understanding of the problem and allow the customer to
voice his or her perceptions about a solution
• How would you characterize "good" output that would be
generated by a successful solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the business environment in
which the solution will be used?
• Will special performance issues or constraints affect the
way the solution is approached?
19. 19
The Final Set of Questions
These questions focus on the effectiveness of the
communication activity itself
• Are you the right person to answer these questions? Are
your answers "official"?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?
20. Elicitation
• It certainly simple enough, but…
• Why difficult
– Problem of Scope
• The boundary of the system is ill-defined
– Problem of Understanding
• The customer/users are not completely sure of what is needed
– Problem of volatility
• The requirement change over time
• To help overcame these problem, requirement engineers
,must approach the requirement gathering activity in an
organized manner
21.
22. Elicitation Process Guideline
– meetings are conducted and attended by both
software engineers and customers
– rules for preparation and participation are
established
– an agenda is suggested
– a "facilitator" (can be a customer, a developer, or
an outsider) controls the meeting
– a "definition mechanism" (can be work sheets, flip
charts, or wall stickers or an electronic bulletin
board, chat room or virtual forum) is used
– the goal is
• to identify the problem
• propose elements of the solution
• negotiate different approaches, and
• specify a preliminary set of solution requirements
23. Elaboration
• Expand requirement into analysis model
• Elements of the analysis model
– Scenario-based elements
• Functional—processing narratives for software
functions
• Use-case—descriptions of the interaction
between an “actor” and the system
– Class-based elements
• Implied by scenarios
– Behavioral elements
• State diagram
– Flow-oriented elements
• Data flow diagram
24.
25. Negotiation
• Agree on a deliverable system that is realistic
for developers and customers
• SW team & other project stakeholders negotiate
the priority, availability, and cost of each
requirement
• The Process are :
– Identify the key stakeholders
• These are the people who will be involved in the negotiation
– Determine each of the stakeholders “win conditions”
• Win conditions are not always obvious
– Negotiate
• Work toward a set of requirements that lead to “win-win”
26. 26
The Art of Negotiation
• Recognize that it is not competition
• Map out a strategy
• Listen actively
• Focus on the other party’s interests
• Don’t let it get personal
• Be creative
• Be ready to commit
27.
28. Specification
• Final work product produced by requirement
engineer.
• Can be any one (or more) of the following:
– A written document
– A set of models
– A formal mathematical
– A collection of user scenarios (use-cases)
– A prototype
29. 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
29
30. Validation
examine the specification to ensure that SW requirement is
not ambiguous, consistent, error free etc
A review mechanism that looks for
• errors in content or interpretation
• areas where clarification may be required
• missing information
• inconsistencies (a major problem when large products or systems
are engineered)
• conflicting or unrealistic (unachievable) requirements.
31. Validation Vs. Verification
• Validation: “Am I building the right product?”
checking a work product against higher-level work
products or authorities that frame this particular
product.
– Requirements are validated by stakeholders
• Verification: “Am I building the product right?”
checking a work product against some standards
and conditions imposed on this type of product
and the process of its development.
– Requirements are verified by the analysts mainly
32. Validation Cont’d
• A review of the analysis model addresses the
following question :
– Is each requirement consistent with the overall
objective for the system/product?
– Have all requirements been specified at the proper level
of abstraction? That is, do some requirements provide a
level of technical detail that is inappropriate at this
stage?
– Is the requirement really necessary or does it represent
an add-on feature that may not be essential to the
objective of the system?
– Is each requirement bounded and unambiguous?
– Does each requirement have attribution? That is, is a
source (generally, a specific individual) noted for each
requirement?
– Do any requirements conflict with other requirements?
37. Information on QFD….
• Developed in Japan in the mid 1970s
• Introduced in USA in the late 1980s
• Toyota was able to reduce 60% of cost
to bring a new car model to market
• Toyota decreased 1/3 of its
development time
• Used in cross functional teams
• Companies feel it increased customer
satisfaction
38. Why….?
• Product should be designed to reflect
customers’ desires and tastes.
• House of Quality is a kind of a conceptual
map that provides the means for
interfunctional planning and communications
• To understand what customers mean by
quality and how to achieve it from an
engineering perspective.
• HQ is a tool to focus the product
development process
39. Important points
• Should be employed at the beginning of every
project (original or redesign)
• Customer requirements should be translated into
measurable design targets
• It can be applied to the entire problem or any
subproblem
• First worry about what needs to be designed then
how
• It takes time to complete
40. Components of
House of Quality
Customer
Evaluation
Units
Targets
This Product
This Product
Who
Whats
Who vs.
Whats
Hows vs
Hows
Hows
Whats vs
Hows
Now
Now vs
What
How Muches
Hows vs
How
Muches
41.
42. Step 1: Who are the
customers?
• To “Listen to the voice of the customer”
first need to identify the customer
• In most cases there are more than one
customer
– consumer
– regulatory agencies
– manufacturing
– marketing/Sales
Customer
Evaluation
Units
Targets
This Product
This Product
Who
Whats
Who vs.
Whats
Hows vs
Hows
Hows
Whats vs
Hows
Now
Now vs
What
How Muches
Hows vs
How
Muches
Customers drive the development of
Customers drive the development of
the product, not the designer
the product, not the designer
43. Step 2: Determine the
customers’ requirements
• Need to determine what is to
be designed
• Consumer
– product works as it should
– lasts a long time
– is easy to maintain
– looks attractive
– incorporated latest technology
– has many features
Customer
Evaluation
Units
Targets
This Product
This Product
Who
Whats
Who vs.
Whats
Hows vs
Hows
Hows
Whats vs
Hows
Now
Now vs
What
How Muches
Hows vs
How
Muches
List all the demanded
qualities at the same level
of abstraction
44. Step 2: cont...
• Manufacturing
– easy to produce
– uses available resources
– uses standard components and methods
– minimum waste
• Marketing/Sales
– Meets customer requirements
– Easy to package, store, and transport
– is suitable for display
45. Kano Model
Basic Quality: These requirements are
not usually mentioned by customers.
These are mentioned only when they are
Excitement
absent from the product.
Performance Quality: provides an
Satisfiers
increase in satisfaction as performance
improves
Excitement Quality or “wow requirements”: are often
unspoken, possibly because we are seldom asked to
express our dreams. Creation of some excitement features
in a design differentiates the product from competition.
Delighted
Performance
Basic
Fully
implemented
Absent
Customer Satisfaction
+
-
Disgusted
46. Types of customer
requirements
• Functional requirements describe the product’s
desired behavior
• Human factors
• Physical requirements
• Reliability
• Life-cycle concerns
• Resource concerns
• Manufacturing requirements
47. How to determine
the Whats?
• Customer survey (have to formulate the
questions very carefully)
• If redesign, observe customers using
existing products
• Combine both or one of the approaches
with designer knowledge/experience to
determine “the customers’ voice”
48. Step 3: Determine Relative
Importance of the Requirements:
Who vs. What
• Need to evaluate the importance of
each of the customer’s requirements.
– Generate weighing factor for each
requirement by rank ordering or other
methods Customer
Evaluation
Units
Targets
This Product
This Product
Who
Whats
Who vs.
Whats
Hows vs
Hows
Hows
Whats vs
Hows
Now
Now vs
What
How Muches
Hows vs
How
Muches
49. Rank Ordering
• Order the identified customer requirements
• Assign “1” to the requirement with the lowest
priority and then increase as the requirements
have higher priority.
• Sum all the numbers
• The normalized weight
Rank/Sum
• The percent weight is: Rank*100/Sum
50. Step 4: Identify and Evaluate the
Competition: How satisfied is the customer
now?
• The goal is to determine how the customer perceives
the competition’s ability to meet each of the
requirements
– it creates an awareness of what already exists
– it reveals opportunities to improve on what already exists
The design:
1. does not meet the requirement at all
2. meets the requirement slightly
3. meets the requirement somewhat
4. meets the requirement mostly
5. fulfills the requirement completely
Customer
Evaluation
Units
Targets
This Product
This Product
Who
Whats
Who vs.
Whats
Hows vs
Hows
Hows
Whats vs
Hows
Now
Now vs
What
How Muches
Hows vs
How
Muches
51. Step 5: Generate Engineering
Specifications: How will the
customers’ requirements be met?
• The goal is to develop a set of engineering
specifications from the customers’ requirements.
Restatement of the design problem and customer requirements in
terms of parameters that can be measured.
Each customer requirement should have at
least one engineering parameter.
Customer
Evaluation
Units
Targets
This Product
This Product
Who
Whats
Who vs.
Whats
Hows vs
Hows
Hows
Whats vs
Hows
Now
Now vs
What
How Muches
Hows vs
How
Muches
52. Step 6: Relate Customers’
requirements to Engineering
Specifications: Hows measure Whats?
• This is the center portion of the house. Each cell
represents how an engineering parameter relates
to a customers’ requirements.
Customer
Evaluation
Units
Targets
This Product
This Product
Who
Whats
Who vs.
Whats
Hows vs
Hows
Hows
Whats vs
Hows
Now
Now vs
What
How Muches
Hows vs
How
Muches
9 = Strong Relationship
3 = Medium Relationship
1 = Weak Relationship
Blank = No Relationship at all
53. Step 7: Identify Relationships Between
Engineering Requirements: How are the
Hows Dependent on each other?
• Engineering specifications maybe
dependent on each other.
Customer
Evaluation
Units
Targets
This Product
This Product
Who
Whats
Who vs.
Whats
Hows vs
Hows
Hows
Whats vs
Hows
Now
Now vs
What
How Muches
Hows vs
How
Muches
9 = Strong Relationship
3 = Medium Relationship
1 = Weak Relationship
-1 = Weak Negative Relationship
-3 = Medium Negative Relationship
-9 = Strong Negative Relationship
Blank = No Relationship at all
54. Step 8: Set Engineering Targets:
How much is good enough?
• Determine target value for
each engineering requirement.
– Evaluate competition products
to engineering requirements
– Look at set customer targets
– Use the above two information
to set targets
Customer
Evaluation
Units
Targets
This Product
This Product
Targets
Who
Whats
Who vs.
Whats
Hows vs
Hows
Hows
Whats vs
Hows
Now
Now vs
What
How Muches
Hows vs
How
Muches
