Requirements engineering involves multiple tasks to ensure software engineers understand customer needs. It begins with inception to establish basic understanding, then elicitation gathers requirements from stakeholders. During elaboration, requirements are analyzed and modeled. Negotiation reconciles customer wants with feasibility. Requirements are then specified and validated before being managed throughout the project. The goals are to avoid building the wrong solution and establish a solid foundation for design.
Double Revolving field theory-how the rotor develops torque
req engg (1).ppt
1. Why Requirements Engineering?
• Requirements engineering helps software engineers
better understand the problems they are trying to
solve
• Building an elegant computer solution that ignores
the customer's needs helps no one. Good
requirements engineering helps in avoiding such
situations
2. What is Requirements Engineering?
• Begins during the communication activity and continues
into the modeling activity
• The intent of requirements engineering is to produce a
written understanding of the customer's problem
• Several different work products might be used to
communicate this understanding (user scenarios, function
and feature lists, analysis models, or specifications)
• In some cases requirements engineering may be
abbreviated, but it is never abandoned
• The development team must understand the requirements
before trying to solve the problem
3. Who does Requirements Engineering?
• Software Engineers (sometimes referred as System
Analysts)
• Stakeholders from the software’s customer side
–Managers
–Customers
–End-users
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
Most importantly, we fail to establish a solid foundation for the system
or software that the user wants built
6. The Problems with our
Requirements Practices (continued)
• Many software developers argue that
–
–
–
– Building software is so compelling that we want to jump right in (before
having a clear understanding of what is needed)
Things will become clear as we build the software
Project customer will be able to better understand what they need only after
examining early stages of the software
Things change so rapidly that requirements engineering is a waste of time
•
•
All of these arguments contain some truth, especially for small
projects that take less than one month to complete
However, as software grows in size and complexity, these arguments
begin to break down and can lead to a failed software project
7. 7
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
9. 9
Requirements Engineering
• 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.
10. 10
Requirements Engineering Steps-I
1. Inception—ask a set of questions that establish …
basic understanding of the problem
the people who want a solution
the nature of the solution that is desired, and
the effectiveness of preliminary communication and collaboration
between the customer and the developer
2. Elicitation—elicit requirements from all stakeholders
3. Elaboration—create an analysis model that identifies data,
function and behavioral requirements
4. Negotiation—agree on a deliverable system that is
realistic for developers and customers
11. 11
Requirements Engineering Steps-II
5. Specification—can be one or more of the following:
– A written document
– A set of models
– A formal mathematical model
– A collection of user scenarios (use-cases)
– A prototype
6. Validation—a review mechanism that looks for
– errors in content or interpretation
– areas where clarification may be required
– missing information
– inconsistencies (a major problem with large systems)
– conflicting or unrealistic (unachievable) requirements
7. Requirements management
12. 12
Inception
• Ask “context-free” questions
–Who is behind the request for this work?
–Who will use the solution (product/system)?
–What will be the economic benefits?
–How would you characterize “good” output from the system?
–What problems does this solution address?
–What environment will the product be used in?
–Are you the right person to answer these questions?
–Are these question relevant?
–Can anyone else provide additional information?
–Should I be asking you anything else?
13. 13
Getting Requirements
Right
• “The hardest single part of building a software system is deciding what to
build. No part of the work so cripples the resulting system if done wrong.
No other part is more difficult to rectify later.”
—Fred Brooks
• “The seeds of major software disasters are usually sown within the first
three months of commencing the software project.”
—Capers Jones
• “We spend a lot of time—the majority of project effort—not implementing
or testing, but trying to decide what to build.”
—Brian Lawrence
14. Inception Task/ Initiating the Requirement
Engineering Process
14
• 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 customer Recognize multiple
viewpoints Work toward collaboration
Break the ice and initiate the communication
15. 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
15
16. 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?
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
16
17. 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
17
19. 19
Elicitation/ Eliciting Requirements
• Why is it so difficult to clearly understand what the customer wants?
–Scope
•The boundary of the system is ill-defined.
•Customers/users specify unnecessary technical detail that may confuse
rather than clarify objectives.
–Understanding
•Customers are not completely sure of what is needed.
•Customers have a poor understanding of the capabilities and
limitations of the computing environment.
•Customers don’t have a full understanding of their problem domain.
•Customers have trouble communicating needs to the system engineer.
•Customers omit detail that is believed to be obvious.
•Customers specify requirements that conflict with other requirements.
•Customers specify requirements that are ambiguous or untestable.
–Volatility
•Requirements change over time.
20. 20
Collaborative Requirements
Gathering
• Meetings are attended by all interested stakeholders.
• Rules established for preparation and participation.
• Agenda should be formal enough to cover all important points, but informal
enough to encourage the free flow of ideas.
• A facilitator controls the meeting.
• A definition mechanism (blackboard, flip charts, etc.) is used.
• During the meeting:
–The problem is identified.
–Elements of the solution are proposed.
–Different approaches are negotiated.
–A preliminary set of solution requirements are obtained.
–The atmosphere is collaborative and non-threatening.
21. Elicitation Task
21
• Eliciting requirements is difficult because of
– Problems of scope in identifying the boundaries of the system or
specifying too much technical detail rather than overall system objectives
– Problems of understanding what is wanted, what the problem domain is,
and what the computing environment can handle (Information that is
believed to be "obvious" is often omitted)
• Elicitation may be accomplished through two activities
–
–
Collaborative requirements gathering
Quality function deployment
22. Basic Guidelines of Collaborative
Requirements Gathering
22
•
•
•
•
•
•
Meetings are conducted and attended by both software engineers,
customers, and other interested stakeholders
Rules for preparation and participation are established
An agenda is suggested that is formal enough to cover all important
points but informal enough to encourage the free flow of ideas
A "facilitator" (customer, developer, or outsider) controls the meeting
A "definition mechanism" is used such as work sheets, flip charts, wall
stickers, electronic bulletin board, chat room, or some other virtual
forum
The goal is to identify the problem, propose elements of the solution,
negotiate different approaches, and specify a preliminary set of
solution requirements
23. 23
Quality Function Deployment
• This is a technique that translates the needs of the customer into
technical requirements for software
• It emphasizes an understanding of what is valuable to the customer
and then deploys these values throughout the engineering process
through functions, information, and tasks
• It identifies three types of requirements
–Normal requirements: These requirements are the objectives and goals stated
for a product or system during meetings with the customer
–Expected requirements: These requirements are implicit to the product or
system and may be so fundamental that the customer does not explicitly state
them
–Exciting requirements: These requirements are for features that go beyond
the customer's expectations and prove to be very satisfying when present
24. 24
Quality Function
Deployment
• Function deployment determines the “value” (to the
customer) of each function required of the system.
• Information deployment identifies data objects and
events.
• Task deployment examines the behavior of the
system.
• Value analysis determines the priority of
requirements.
25. Ref: Software Engineering: A
Non-Functional Requirements (NFR)
• NFRs are the quality, performance, and security
attributes, general system constraints (e.g. max available
RAM), or process requirements (e.g. IDE)
• Generally apply to the whole system rather than any
particular feature
• Often not easy for stakeholders to articulate
• There is an overemphasis on functionality of the
software, yet the software may not be useful or usable
without the necessary non-functional characteristics
26.
27. 27
Elicitation Work Products
• A statement of need and feasibility
• A bounded statement of scope for the system or product
• A list of customers, users, and other stakeholders who participated in
requirements elicitation
• A description of the system's technical environment
• A list of requirements (organized by function) and the domain
constraints that apply to each
• A set of preliminary usage scenarios (in the form of use cases) that
provide insight into the use of the system or product under different
operating conditions
• Any prototypes developed to better define requirements
The work products will vary depending on the system, but
should include one or more of the following items
28. 28
Example - CAMU
• Normal Requirement:
–Attendance update by Faculty
–Attendance report for Faculty /Students
• Expected Requirement:
- Attendance lag report
• Exciting Requirement:
– Sending alert to Parents
29. 29
Elicitation Work Products
• Statement of need and feasibility.
• Statement of scope.
• List of participants in requirements elicitation.
• Description of the system’s technical environment.
• List of requirements and associated domain
constraints.
• List of usage scenarios.
• Any prototypes developed to refine requirements.
31. Elaboration Task
31
•
•
•
During elaboration, the software engineer takes the information
obtained during inception and elicitation and begins to expand and
refine it
Elaboration focuses on developing a refined technical model of
software functions, features, and constraints
The end result is an analysis model that defines the functional,
informational, and behavioral domains of the problem
32. 32
Elaboration Task
• During elaboration, the software engineer takes the information
obtained during inception and elicitation and begins to expand
and refine it
• Elaboration focuses on developing a refined technical model of
software functions, features, and constraints
• It is an analysis modeling task
–Use cases are developed
–Domain classes are identified along with their attributes and relationships
–State machine diagrams are used to capture the life on an object
• The end result is an analysis model that defines the functional,
informational, and behavioral domains of the problem
34. Negotiation Task
34
•
•
•
•
•
During negotiation, the software engineer reconciles the conflicts
between what the customer wants and what can be achieved given
limited business resources
Requirements are ranked (i.e., prioritized) by the customers, users, and
other stakeholders
Risks associated with each requirement are identified and analyzed
Rough guesses of development effort are made and used to assess the
impact of each requirement on project cost and delivery time
Using an iterative approach, requirements are eliminated, combined
and/or modified so that each party achieves some measure of
satisfaction
35. The Art of Negotiation
35
•
•
•
•
•
•
•
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
37. Specification Task
37
•
•
•
•
•
A specification is the final work product produced by the requirements
engineer
It is normally in the form of a software requirements specification
It serves as the foundation for subsequent software engineering
activities
It describes the function and performance of a computer-based system
and the constraints that will govern its development
It formalizes the informational, functional, and behavioral
requirements of the proposed software in both a graphical and textual
format
39. Validation Task
39
•
•
During validation, the work products produced as a result of
requirements engineering are assessed for quality
The specification is examined to ensure that
–
–
–
all software requirements have been stated unambiguously
inconsistencies and errors have been detected and corrected
the work products conform to the standards established for the process,
the project, and the product
• The formal technical review serves as the primary requirements
validation mechanism
– Members include software engineers, customers, users, and
other stakeholders
41. Requirements Management Task
41
•
•
•
• During requirements management, the project team performs a set of
activities to identify, control, and track requirements and changes to
the requirements at any time as the project proceeds
Each requirement is assigned a unique identifier
The requirements are then placed into one or more traceability tables
These tables may be stored in a database that relate features, sources,
dependencies, subsystems, and interfaces to the requirements
45. 45
Use-Cases
• A use-case scenario is a story about how someone or something
external to the software (known as an actor) interacts with the system.
• Each scenario answers the following questions:
• Who is the primary actor, the secondary actor(s)?
–What are the actor’s goals?
–What preconditions should exist before the story begins?
–What main tasks or functions are performed by the actor?
–What exceptions might be considered as the story is described?
–What variations in the actor’s interaction are possible?
–What system information will the actor acquire, produce, or change?
–Will the actor have to inform the system about changes in the external
environment?
–What information does the actor desire from the system?
–Does the actor wish to be informed about unexpected changes?
46. 46
Elements of the Analysis Model
• Scenario-based elements
–Use-case—How external actors interact with the system (use-
case diagrams; detailed templates)
–Functional—How software functions are processed in the
system (flow charts; activity diagrams)
• Class-based elements
–The various system objects (obtained from scenarios) including
their attributes and functions (class diagram)
• Behavioral elements
–How the system behaves in response to different events (state
diagram)
• Flow-oriented elements
–How information is transformed as if flows through the system
(data flow diagram)
51. 51
Analysis Patterns
Pattern name: Captures the essence of the pattern.
Intent: What the pattern accomplishes or represents.
Motivation: A scenario that illustrates how the pattern solves a
problem.
Forces and context: External issues (forces) that affect how the
pattern is used, and external issues resolved when the
pattern is applied.
Solution: How the pattern is applied to solve the problem;
emphasizes structural and behavioral issues.
Consequences: What happens when the pattern is applied; what
trade-offs exist during its application.
Design: How the pattern can be achieved via known design
patterns.
Known uses: Examples of uses within actual systems.
Related patterns: Patterns related to the named pattern because
(1) they are commonly used with the named pattern;
(2) they are structurally similar to the named pattern;
(3) they are a variation of the named pattern.
52. 52
Negotiating Requirements
• 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”
53. 53
Validating Requirements
• Is each requirement consistent with the objective of the system?
• Have all requirements been specified at the proper level of abstraction?
• Is the requirement really necessary?
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution?
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the system’s technical environment?
• Is each requirement testable, once implemented?
• Does the model reflect the system’s information, function and
behavior?
• Has the model been appropriately “partitioned”?
• Have appropriate requirements patterns been used?
54. 54
Example CRG Meeting
• First CRG meeting of the SafeHome project.
–After Q&A session (inception meeting), stakeholders write a two
page product request, which is delivered to those attending the first
CRG meeting.
–Attendees are asked to make a rough list of objects, services,
constraints, and performance criteria for the product.
–At the meeting, a combined list is created in each topic.
–Subgroups write mini-specifications for each list item.
–Relevant features in mini-specifications are added to the list.
55. 55
Example CRG Meeting
• Our research indicates that the market for home management systems is
growing at a rate of 40 percent per year. The first SafeHome function we
bring to market should be the home security function. Most people are
familiar with “alarm systems” so this would be an easy sell.
• The home security function would protect against and/or recognize a
variety of undesirable “situations” such as illegal entry, fire, flooding,
carbon monoxide levels, and others. It’ll use our wireless sensors to
detect each situation, can be programmed by the homeowner, and will
automatically telephone a monitoring agency when a situation is
detected.
56. 56
Example CRG Meeting
• Objects – control panel, smoke detectors, window and door sensors,
motion detectors, an alarm, an event (sensor has been activated), a
display, a PC, telephone numbers, a telephone call, …
• Services – configuring the system, setting the alarm, monitoring the
sensors, dialing the phone, programming the control panel, reading the
display, …
• Constraints – System must recognize when sensors are not operating,
must be user friendly, must interface directly to a standard phone line, …
• Performance criteria – Sensor event should be recognized within one
second, an event priority scheme should be implemented, …
57. 57
Example CRG Meeting
• Mini-specification for Control Panel
–The Control Panel is a wall-mounted unit that is
approximately 9 x 5 inches in size. The control
panel has wireless connectivity to sensors and a PC.
User interaction occurs through a keypad
containing 12 keys. A 2 x 2 inch LCD display
provides user feedback. Software provides
interactive prompts, echo, and similar functions.
58. Quality Function Deployment
58
•
•
•
This is a technique that translates the needs of the customer into
technical requirements for software
It emphasizes an understanding of what is valuable to the customer
and then deploys these values throughout the engineering process
through functions, information, and tasks
It identifies two types of requirements
– Normal requirements: These requirements are the objectives and goals
stated for a product or system during meetings with the customer
– Expected requirements: These requirements are implicit to the product or
system and may be so fundamental that the customer does not explicitly
state them
59. These slides are designed to
59
Use-Cases
• Scenarios that describe the threads of usage of a system
• Each scenario is described from the point-of-view of an “actor”—a
person or device that interacts with the software in some way
• Each scenario answers the following questions:
oWho is the primary actor, the secondary actor(s)?
oWhat are the actor’s goals?
oWhat preconditions should exist before the story begins?
oWhat main tasks or functions are performed by the actor?
oWhat extensions might be considered as the story is described?
oWhat variations in the actor’s interaction are possible?
oWhat system information will the actor acquire, produce, or change?
oWill the actor have to inform the system about changes in the external
environment?
oWhat information does the actor desire from the system?
oDoes the actor wish to be informed about unexpected changes?
60. Actors
• An actor is anything that communicates with the
system and that is external to the system itself. Every
actor has one or more goals when using the system
• It is important to note that an actor and an end-user
are not necessarily the same thing. A typical user
may play a number of different roles when using a
system
• Primary actors interact to achieve required system
function and derive the intended benefit from the
system. They work directly with the system
• Secondary actors support the system so that primary
actors can do their work
Ref: Software Engineering: A
61. Use Case Example for Operating
the SafeHome Control Panel
Ref: Software Engineering: A
62. Ref: Software Engineering: A
6. Scenario:
Homeowner: observes control panel
Homeowner: enters password
Homeowner: selects “stay” or “away”
Homeowner: observes read alarm light to
indicate that SafeHome has
been armed
1. Use case: InitiateMonitoring
2. Primary actor: Homeowner
3. Goal in context: To set the system to monitor
sensors when the
homeowner leaves the
house or remains inside
4. Preconditions: System has been
programmed for a password
and to recognize various
sensors
5. Trigger: The homeowner decides to
“set” the system, that is, to
turn on the alarm functions
7. Exceptions:
Control panel is not ready: homeowner checks all sensors to determine which are open; closes them
Password is incorrect (control panel beeps once): homeowner reenters correct password.
Password not recognized: monitoring and response subsystem must be contacted to reset password
Stay is selected: control panel beeps twice and a stay light is lit; perimeter sensors are activated
Away is selected: control panel beeps three times and an away light is lit; all sensors are activated
8. Priority: Essential, must be
implemented
9. When available: First increment
10. Frequency of use: Many times per day
11. Channel to actor: Via control panel interface
12. Secondary actors: Support technician, sensors
13. Channels to secondary actors:
Support technician: phone line
Sensors: hardwired and wireless interfaces
14. Open issues:
1. Should there be a way to activate the
system without the use of a password or
with an abbreviated password?
2. Should the control panel display additional
text messages?
3. How much time does the homeowner have
to enter the password from the time the first
key is pressed?
4. Is there a way to deactivate the system
before it actually activates?
63. Use Case: InitialMonitoring (1)
Ref: Software Engineering: A
Use case: InitiateMonitoring
Primary actor: Homeowner
Goal in context: To set the system to monitor sensors when the
homeowner leaves the house or remains inside
Preconditions: System has been programmed for a password
and to recognize various sensors
Trigger: The homeowner decides to “set” the system, that
is, to turn on the alarm functions
64. Use Case: InitialMonitoring (2)
Ref: Software Engineering: A
Scenario:
Homeowner: observes control panel
Homeowner: enters password
Homeowner: selects “stay” or “away”
Homeowner: observes read alarm light to indicate that
SafeHome has been armed
65. Use Case: InitialMonitoring (3)
Ref: Software Engineering: A
Exceptions:
Control panel is not ready: homeowner checks all sensors to determine
which are open; closes them
Password is incorrect (control panel beeps once): homeowner reenters
correct password.
Password not recognized: monitoring and response subsystem must be
contacted to reset password
Stay is selected: control panel beeps twice and a stay light is lit;
perimeter sensors are activated
Away is selected: control panel beeps three times and an away light is
lit; all sensors are activated
66. Use Case: InitialMonitoring (4)
Ref: Software Engineering: A
Priority: Essential, must be implemented
When available: First increment
Frequency of use: Many times per day
Channel to actor: Via control panel interface
Secondary actors: Support technician, sensors
Channels to secondary actors:
Support technician: phone line
Sensors: hardwired and wireless interfaces
67. Use Case: InitialMonitoring (5)
Ref: Software Engineering: A
Open issues:
1. Should there be a way to activate the system without the use
of a password or with an abbreviated password?
2. Should the control panel display additional text messages?
3. How much time does the homeowner have to enter the
password from the time the first key is pressed?
4. Is there a way to deactivate the system before it actually
activates?
68. These slides are designed to
Use-Case
Diagram
for the
SafeHome
System
Initial
Monitoring
69. These slides are designed to
69
Elements of the
Analysis/Requirements Model
1. Scenario-based elements
Use-case diagram and use-case descriptions
2. Class-based elements
Class diagram
3. Behavioral elements
State diagram
71. Class Diagram
These slides are designed to
71
Sensor
name/id
type
location
area
characteristics
identify()
enable()
disable()
reconfigure ()
For the SafeHome system …
72. State Diagram
These slides are designed to
72
Reading
Commands
System status = “ready”
Display msg = “enter cmd”
Display status = steady
Entry/subsystems ready
Do: poll user input panel
Do: read user input
Do: interpret user input
State name
State variables
State activities
73. Analysis/Requirements Patterns
• Are classes/functions/behaviors that reoccur
across many projects in a particular
application domain
• They speed up the development of the
analysis model by providing reusable analysis
models with examples and descriptions of
advantages and limitations
• The facilitate the transformation of analysis to
design by suggesting related design pattern
and reliable solutions to common problems
74. These slides are designed to
74
Analysis/Requirements Patterns:
Template
Pattern name: A descriptor that captures the essence of the pattern
Intent: Describes what the pattern accomplishes or represents
Motivation: A scenario that illustrates how the pattern can be used to
address the problem
Forces and context: A description of external issues (forces) that
can affect how the pattern is used and also the external issues
that will be resolved when the pattern is applied
Solution: A description of how the pattern is applied to solve the
problem with an emphasis on structural and behavioral issues
Consequences: Addresses what happens when the pattern is
applied and what trade-offs exist during its application
Design: Discusses how the analysis pattern can be achieved through
the use of known design patterns
Known uses: Examples of uses within actual systems
Related patterns: Patterns that are commonly used with this pattern,
or are structurally similar, or are a variation of this pattern
75. Negotiating Requirements:
Why?
• Negotiate to balance customer’s functionality and
performance requirements against available
resources (time, people, budget, etc.)
• Intent of negotiation is to agree upon a project plan
that meets the needs of the customer while
reflecting the real-world constraints of time, people,
and budget
• The best negotiation strives for a win-win result:
–A majority of the customer’s needs are met
–The developer gets to work to achievable deadlines within a
76. These slides are designed to
76
Negotiating Requirements:
How?
1. Identify the key stakeholders
These are the people who will be involved in the
negotiation
2. Determine each of the stakeholders “win
conditions”
Win conditions are not always obvious
3. Negotiate
Work toward a set of requirements that lead to “win-
win”
77. Negotiating Requirements: Guidelines
• It's not a competition
• Map out a strategy
• Listen actively
• Focus on other party's interests
• Don't let it get personal
• Be creative
• Be ready to commit
78. These slides are designed to
78
Requirements Monitoring:
Especially Needed in Incremental Development
Requirements monitoring supports continuous
validation by analyzing user goals against the system
developed
Distributed debugging – uncovers errors and determines
their cause
Run-time verification – determines whether software
matches its specification
Run-time validation – assesses whether evolving software
meets user goals
Business activity monitoring – evaluates whether a system
satisfies business goals
Evolution and co-design – provides information to
stakeholders as the system evolves
79. Validating
Requirements - I
• 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?
These slides are designed to
79
80. Validating
Requirements - II
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution? That is,
is a source noted for each requirement?
• Do any requirements conflict with other
requirements?
• Is each requirement achievable in the technical
environment that will house the system or
product?
• Is each requirement testable, once implemented?
These slides are designed to
80
81. Validating
Requirements - III
• Does the requirements model properly reflect
the information, function and behavior of the
system to be built?
• Has the requirements model been “partitioned”
in a way that exposes progressively more
detailed information about the system?
• Have requirements patterns been used to
simplify the requirements model? Have all
patterns been properly validated? Are all
patterns consistent with customer
These slides are designed to
81
82. Avoiding Common
Mistakes
Fearturitis describes the practice of trading functional
coverage for overall system quality. Some engineers equate
the number of functions delivered at the earliest possible
time with the overall quality of the end product
Flexibilitis happens when engineers overload the product
with adaptation and configuration facilities. The result is a
system that is unnecessarily complex, more difficult to test,
and more challenging to manage
Performitis occurs when developers become overly focused
on system performance at the expense of quality attributes,
e.g. maintainability, reliability, security
Ref: Software Engineering: A
