Requirement Requirement EngineeringEngineering
Preeti MishraPreeti Mishra
Course InstructorCourse Instructor
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
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
Types of Types of RequirementsRequirements
• 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
Requirements of Requirements of RequirementsRequirements
• Clear
• Measurable
• Feasible
• Necessary
• Prioritized
• Concise8
Why Req Eng is Difficult
9
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
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
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
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
14
RequirementsManagement
Validation
Inception
Elicitation
Elaboration
Negotiation
Specification
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
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
The First Set of Questions
• 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?
These questions focus on the customer, other stakeholders, the overall goals, and the benefits
18
The Next Set of Questions
• 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?
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
19
The Final Set of Questions
• 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?
These questions focus on the effectiveness of the communication activity itself
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
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
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
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
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
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
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
Validation
examine the specification to ensure that SW requirement isnot 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.
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
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?
33
Summary
RequirementsManagement
Validation
Inception
Elicitation
Elaboration
Negotiation
Specification
The problems is not that there are problems. The problem is expecting otherwise and thinking that having problems is a problem
Theodore Rubin
Need to focus
Moving in the wrong direction at a fast pace is still moving in the wrong direction.
Wrong
Right
Quality Function Deployment
QFD
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
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
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
Components of House of Quality
Customer Evaluation
Units
Targets
Th
is P
rod
uct
This Product
Targets
Who
Whats
Wh
o vs
. W
hat
s
Hows vs Hows
Hows
Whats vs Hows
Now
No
w v
s W
hat
How MuchesHows vs
How Muches
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
Th
is P
rod
uct
This Product
Targets
Who
Whats
Who
vs.
Wha
ts
Hows vsHows
Hows
Whats vsHows
Now
Now
vs
Wha
t
How MuchesHows vs
HowMuches
Customers drive the development of the product, not the designer
Customers drive the development of the product, not the designer
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
Th
is P
rod
uct
This Product
Targets
Who
Whats
Who
vs.
Wha
ts
Hows vsHows
Hows
Whats vsHows
Now
Now
vs
Wha
t
How MuchesHows vs
HowMuches
List all the demanded qualities at the same level
of abstraction
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
Kano Model
Excitement
SatisfiersBasic
Perfo
rman
ce
Fullyimplemented
Absent
Customer Satisfaction
-
+
Disgusted
Delighted
Basic Quality: These requirements are not usually mentioned by customers. These are mentioned only when they are absent from the product.
Performance Quality: provides an 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.
Types of customer requirements
• Functional requirements describe the product’s desired behavior
• Human factors• Physical requirements• Reliability• Life-cycle concerns• Resource concerns• Manufacturing requirements
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”
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
Th
is P
rod
uct
This Product
Targets
Wh
o
Whats
Who
vs.
Wha
ts
Hows vsHows
Hows
Whats vsHows
Now
Now
vsW
hat
How MuchesHows vs
HowMuches
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
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 all2. meets the requirement slightly3. meets the requirement somewhat4. meets the requirement mostly5. fulfills the requirement completely
Customer Evaluation
Units
Targets
Th
is P
rod
uct
This Product
Targets
Wh
o
Whats
Who
vs.
Wha
ts
Hows vsHows
Hows
Whats vsHows
Now
Now
vsW
hat
How MuchesHows vs
HowMuches
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
Th
is P
rod
uct
This Product
Targets
Wh
o
Whats
Who
vs.
Wha
ts
Hows vsHows
Hows
Whats vsHows
Now
Now
vsW
hat
How MuchesHows vs
HowMuches
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
Th
is P
rod
uct
This Product
Targets
Wh
o
Whats
Who
vs.
Wha
ts
Hows vsHows
Hows
Whats vsHows
Now
Now
vsW
hat
How MuchesHows vs
HowMuches
9 = Strong Relationship3 = Medium Relationship1 = Weak RelationshipBlank = No Relationship at all
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
Th
is P
rod
uct
This Product
Targets
Wh
o
Whats
Who
vs.
Wha
ts
Hows vsHows
Hows
Whats vsHows
Now
Now
vsW
hat
How MuchesHows vs
HowMuches
9 = Strong Relationship3 = Medium Relationship1 = Weak Relationship-1 = Weak Negative Relationship-3 = Medium Negative Relationship-9 = Strong Negative RelationshipBlank = No Relationship at all
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
Th
is P
rod
uct
This Product
Targets
Wh
o
Whats
Who
vs.
Wha
ts
Hows vsHows
Hows
Whats vsHows
Now
Now
vsW
hat
How MuchesHows vs
HowMuches
Top Related