SOFTWARE ENGINEERING AND

PROJECT MANAGEMENT
(BCS501)

Prepared by,
Kavya Jayaprasad
Assistant Professor
AI&ML department
AIEMS, Bidadi
 Course Outcomes

Learning Resources
 Module 2
Understanding Requirements
 Requirements Engineering

 Requirements analysis, also called Requirements engineering, is the process of

determining user expectations for a new or modified product.
 The broad spectrum of tasks and techniques that lead to an understanding of
requirements is called requirements engineering.
 Requirements engineering is a major software engineering action that begins during the
communication activity and continues into the modeling activity.
 Requirements engineering builds a bridge to design and construction.
 Requirements engineering provides the appropriate mechanism for understanding what
the customer wants, analyzing need, assessing feasibility, negotiating a reasonable
solution, specifying the solution unambiguously, validating the specification, and
managing the requirements as they are transformed into an operational system.
 It encompasses seven distinct tasks: inception, elicitation, elaboration, negotiation,
specification, validation, and management.
 Requirements Engineering
Inception

 It establishes a 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 other
stakeholders and the software team.
 Requirements Engineering
Elicitation
 In this stage, proper information is extracted to prepare and document the requirements.
 It certainly seems simple enough, but very hard :
 Ask the customer, the users, and others what the objectives for the system or product
are, what is to be accomplished, how the system or product fits into the needs of the
business, and finally, how the system or product is to be used on a day- to-day basis.
 AS identified by Christel and Clang, problems encountered in Elicitation are:
 Problems of scope. The boundary of the system is ill-defined or the
customers/users specify unnecessary technical detail that may confuse, rather than
clarify, overall system objectives.
 Problems of understanding. The customers/users are not completely sure of what is
needed, have a poor understanding of the capabilities and limitations of their
computing environment, don’t have a full understanding of the problem domain,
have trouble communicating needs to the system engineer, omit information that is
believed to be “obvious,” specify requirements that conflict with the needs of other
customers/users, or specify requirements that are ambiguous or untestable.
 Problems of volatility. In this problem, the requirements change from time to
time and it is difficult while developing the project.
 Requirements Engineering
Elaboration

The information obtained from the customer during inception and

elicitation is expanded and refined during elaboration.

This task focuses on developing a refined requirements model that

identifies various aspects of software function, behavior, and
information.

Elaboration is driven by the creation and refinement of user scenarios

that describe how the end user will interact with the system.
 Requirements Engineering
Negotiation
 Limited resources and conflicting customer needs often
cause requirement clashes. Therefore:
 First, identify conflicts in requirements.
 Ask customers, users, and stakeholders to rank requirements by
priority.
 Discuss conflicts based on these priorities.
 Use an iterative process:
 Prioritize requirements.
 Assess cost and risk.
 Resolve conflicts by eliminating, combining, or modifying
requirements.

 Goal is to ensure all parties are reasonably satisfied.

 Requirements Engineering
Specification
 The term specification means different things to different people.

 A specification can be a written document, a set of graphical models, a formal

mathematical model, a collection of usage scenarios, a prototype, or any
combination of these.

 A “standard template” should be developed and used for a specification.

 For large systems, a written document, combining natural language

descriptions and graphical models may be the best approach.
 Requirements Engineering
Validation
 Requirements validation examines the specification to ensure that all software
requirements have been stated unambiguously; that inconsistencies, omissions,
and errors have been detected and corrected; and that the work products conform
to the standards established for the process, the project, and the product.

 The primary requirements validation mechanism is the technical review.

 The review team that validates requirements includes software engineers,

customers, users, and other stakeholders who examine the specification looking
for errors in content or interpretation, areas where clarification may be required,
missing information, inconsistencies, conflicting requirements, or unrealistic
requirements.
 Requirements Engineering
Requirements management
 Requirements for computer-based systems change, and the desire to change
requirements persists throughout the life of the system.

 It is a set of activities that help the project team to identify, control and track
the requirements and changes can be made to the requirements at any time
of the ongoing project.
 * Additional Information

Task Purpose Key Activities Output

Identify
stakeholders, Preliminary project
Establish the initial
outline business scope, stakeholder
Inception scope and business
objectives, and list, and high-level
need of the project.
define the overall requirements.
vision.
Conduct interviews,
Gather detailed workshops, Raw requirement
Elicitation requirements from observations, list (functional and
stakeholders. questionnaires, and non-functional).
document analysis.
Analyze,
Structured
Refine and model categorize,
requirements, use
Elaboration requirements for prioritize, and
cases, models, and
clarity. resolve ambiguities
prototypes.
in requirements.
 Ranking
Resolve conflicts Agreed-upon set of
Negotiation requirements, trade-
between requirements
off analysis,
stakeholders with acceptable to all
compromise
different priorities. stakeholders.
discussions.
Create Software
Requirement
Document SRS document
Specification (SRS),
Specification requirements clearly (textual, diagrams,
including functional
and formally. models).
and non-functional
requirements.
Validated
Reviews,
Ensure requirements requirements
walkthroughs,
Validation are correct and meet (consistent,
prototyping, test-
stakeholder needs. complete, and
case derivation.
correct).
Updated
Handle changes and Version control,
requirements
evolution of traceability, change
Management baseline, change
requirements over requests, impact
logs, and managed
time. analysis.
requirement set.
 Establishing The Groundwork

 There could be many issues to start Requirement Engineering Process:

 Customers or end users may be located in a different city/country.
 Customers do not have a clear idea of the requirements.
 Lack of technical knowledge or customers have limited time to interact with
requirement engineer.
 Hence by following the below steps we can start a requirement engineering
process:
 Identifying Stakeholders
 Recognizing Multiple Viewpoints
 Working toward Collaboration
 Asking the First Questions
 * Additional Information
Step Purpose Key Focus Outcome
Determine who will
be affected by the Users, customers, List of stakeholders
Identifying
system or who has managers, regulators, with roles and
Stakeholders
input into developers. responsibilities.
requirements.

Understand that
Functional needs,
different Collection of diverse
Recognizing performance,
stakeholders have perspectives on the
Multiple Viewpoints security, usability,
different needs and system.
cost, etc.
expectations.

Bring stakeholders Group discussions, Shared

Working Toward together to resolve workshops, conflict understanding of
Collaboration differences and align resolution, consensus requirements
objectives. building. priorities.

Scope, objectives,
Start gathering initial Preliminary
Asking the First key features, system
requirements and requirement set and
Questions boundaries,
constraints. clarified goals.
limitations.
 Identifying Stakeholders
 Stakeholder is the one who benefits in a direct or indirect way from the system
which is being developed.
 Business operations managers, product managers, marketing people, internal
and external customers, end users, consultants, product engineers, software
engineers, support and maintenance engineers, and others.
 Each stakeholder has a different view of the system, achieves different benefits
when the system is successfully developed, and is open to different risks if the
development effort should fail.
 Recognizing Multiple Viewpoints

 As many stakeholders exist, they all have different views regarding the
system to be developed, hence it is the duty of software engineers to
consider all the viewpoints of stakeholders in a way that allows decision
makers to choose an internally consistent set of requirements for the
system
 For example, the marketing group is interested in functions and features
that will excite the potential market, making the new system easy to sell
and End users may want features that are easy to learn and use.
 Working toward Collaboration
 Collaboration does not necessarily mean that requirements are defined by committee.
In many cases, stakeholders collaborate by providing their view of requirements, but
a strong “project champion” (e.g., a business manager or a senior technologist) may
make the final decision about which requirements make the cut.
 Asking the First Questions
 Questions asked at the inception of the project should be “context free”. The
first set of context - free questions focuses on the customer and other
stakeholders, the overall project goals and benefits. For example, you might
ask:
 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 help to identify all stakeholders who will have interest in the
software to be built. Also, the measurable benefit of a successful
implementation and possible alternatives to custom software development.
 The next set of questions enables you to gain a better understanding of the
problem and allows 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?
 Asking the First Questions

 The final set of questions focuses on the effectiveness of the

communication activity itself.
 Gause and Weinberg call these “meta-questions” and propose the following
list:
 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 will help to “break the ice” and initiate the communication
that is essential to successful elicitation.
 Eliciting Requirements

 Requirements Elicitation (also called requirements gathering) combines

elements of problem solving, elaboration, negotiation, and specification.

 In order to encourage a collaborative, team- oriented approach to

requirements gathering, stakeholders work together to identify the problem,
propose elements of the solution, negotiate different approaches and specify a
preliminary set of solution requirements.
 Eliciting Requirements
Collaborative Requirements Gathering
 Many different approaches to collaborative requirements gathering have
been proposed.
 Each makes use of a slightly different scenario, but all apply some variation
on the following basic guidelines:
 Meetings are conducted and attended by both software engineers and other
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” (can be a customer, a developer, or an outsider) controls the
meeting.
 A “definition mechanism” (can be worksheets, 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.
 Collaborative requirements gathering
Scenario: Campus Event Management App
*Additional information
 Step 1: Identify Stakeholders
 Students: Potential users who will attend events.
 Event Organizers: People who will create and manage events.
 University Administration: They might have specific requirements or policies to comply
with.
 Developers: The team responsible for building the app.
 Step 2: Conduct Initial Meetings
 Organize a kickoff meeting with all stakeholders to introduce the project and its goals.
 Use this meeting to explain the importance of gathering accurate requirements and how it
will impact the final product.
 Step 3: Use Collaborative Techniques
 Brainstorming Session
 Surveys and Questionnaires
 Workshops and User Stories.
 Step 4: Document and Validate Requirements
 Step 5: Create a Prototype or Wireframes
 Step 6: Iterate and Improve
 Eliciting Requirements
Collaborative Requirements Gathering

 During inception, basic questions and answers establish the scope of the
problem and the overall perception of a solution.
 Out of these initial meetings, the developer and customers write a one or two
page “product request.”
 A meeting place, time, and date are selected; a facilitator is chosen; and
attendees from the software team and other stakeholder organizations are
invited to participate.
 The product request is distributed to all attendees before the meeting date.
 Eliciting Requirements
Collaborative Requirements Gathering

Example: SafeHome Project

 Consider an excerpt from a product request written by a marketing person involved
in the SafeHome project.
 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.
 It can be programmed by the homeowner, and will automatically telephone a monitoring
agency when a situation is detected.
 In reality, others would contribute to this narrative during the requirements
gathering meeting and considerably more information would be available.
 Eliciting Requirements
Collaborative Requirements Gathering

 While reviewing the product request in the days before the meeting, each
attendee is asked to make a list of objects that are part of the environment that
surrounds the system, other objects that are to be produced by the system, and
objects that are used by the system to perform its functions.

 In addition, each attendee is asked to make another list of services (processes

or functions) that manipulate or interact with the objects.

 Finally, lists of constraints (e.g., cost, size, business rules) and performance
criteria (e.g., speed, accuracy) are also developed.
 Eliciting Requirements
Collaborative Requirements Gathering
 Objects described for SafeHome might include the control panel, smoke
detectors, window and door sensors, motion detectors, an alarm, an event (a
sensor has been activated), a display, a PC, telephone numbers, a telephone call,
and so on.
 The list of services might include configuring the system, setting the alarm,
monitoring the sensors, dialing the phone, programming the control panel, and
reading the display (note that services act on objects).
 In a similar fashion, each attendee will develop lists of constraints (e.g., the
system must recognize when sensors are not operating, must be user-friendly,
must interface directly to a standard phone line) and performance criteria (e.g., a
sensor event should be recognized within one second, and an event priority
scheme should be implemented).
 The lists of objects can be pinned to the walls of the room using large sheets of
paper, stuck to the walls using adhesive-backed sheets, or written on a wall
board.
 Alternatively, the lists may have been posted on an electronic bulletin board, at
an internal website, or posed in a chat room environment for review prior to the
meeting.
 Eliciting Requirements
Collaborative Requirements Gathering
 At this stage, critique and debate are strictly prohibited.
 After individual lists are presented in one topic area, the group creates a combined
list by eliminating redundant entries, adding any new ideas that come up during
the discussion, but not deleting anything.
 After you create combined lists for all topic areas, discussion—coordinated by the
facilitator—ensues.
 The combined list is shortened, lengthened, or reworded to properly reflect the
product/system to be developed.
 The objective is to develop a consensus list of objects, services, constraints, and
performance for the system to be built.
 In many cases, an object or service described on a list will require further
explanation.
 To accomplish this, stakeholders develop mini-specifications for entries on the
lists.
 Eliciting Requirements
Collaborative Requirements Gathering
For example, the mini-spec for the SafeHome object Control Panel might be:
 The control panel is a wall-mounted unit that is approximately 9.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 3.3-inch LCD color
display provides user feedback.
 Software provides interactive prompts, echo, and similar functions.
 The mini-specs are presented to all stakeholders for discussion.
 Additions, deletions, and further elaboration are made.
 In some cases, the development of mini-specs will uncover new objects, services,
constraints, or performance requirements that will be added to the original lists.
 During all discussions, the team may raise an issue that cannot be resolved during
the meeting.
 An issues list is maintained so that these ideas will be acted on later.
 Eliciting Requirements
Quality function deployment (QFD)
 QFD is a quality management technique that translates the needs of the customer into
technical requirements for software.
 QFD identifies three types of requirements:
 Normal requirements. The objectives and goals that are stated for a product or
system during meetings with the customer. If these requirements are present, the
customer is satisfied.
 Expected requirements. These requirements are implicit to the product or system
and may be so fundamental that the customer does not explicitly state them.
 Examples of expected requirements are: ease of human/machine interaction, overall
operational correctness and reliability, and ease of software installation.
 Exciting requirements. These features go beyond the customer’s expectations and
prove to be very satisfying when present.
 For example, the mobile phone with standard features, but the developer adds few
additional functionalities like voice searching, multi-touch screen etc. then the customer
is more excited about that feature.
 QFD uses customer interviews and observation, surveys, and examination of historical
data as raw data for the requirements gathering activity.
 These data are then translated into a table of requirements— called the customer
voice table—that is reviewed with the customer and other stakeholders.
 Eliciting Requirements
Usage Scenarios

 As requirements are gathered, an overall vision of system functions and

features begins to materialize.
 However, it is difficult to move into more technical software engineering
activities until you understand how these functions and features will be
used by different classes of end users.
 To accomplish this, developers and users can create a set of scenarios
that identify a thread of usage for the system to be constructed.
 The scenarios, often called use cases, provide a description of how the
system will be used.
 Eliciting Requirements
Elicitation Work Products
 The work products produced as a consequence of requirements elicitation
will vary depending on the size of the system or product to be built.
 For most systems, the work products include:
 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 and the domain constraints that apply to each.
 A set of usage scenarios that provide insight into the use of the system or product
under different operating conditions.
 Any prototypes developed to better define requirements.

 Each of these work products is reviewed by all people who have participated
in requirements elicitation.
 DEVELOPING USE CASES
 The first step in writing a use case is to define the set of “actors” that will
be involved in the story.
 Actors = People or devices outside the system that interact with it.
 Actor ≠ User always – a user can have many roles, but an actor represents
one role in a use case.
 Primary actors → directly use the system to achieve a goal.
 Secondary actors → help the system function (like technicians, databases,
sensors).
 Each actor has a goal when using the system (e.g., homeowner wants to
arm the alarm).
 Not all actors are known at the start – we discover more as requirements
evolve.
 Once actors are identified → we can write use cases.
 Use case example
*additional information

A use case is a way of describing how an actor (user) interacts with a system to
achieve a specific goal.
Example:
❑ ATM System – Withdraw Cash
 Actor: Bank Customer
 Goal: Withdraw money from ATM
 Use case steps:
 Customer inserts ATM card.
 System asks for PIN.
 Customer enters PIN.
 System verifies PIN.
 Customer selects “Withdraw Cash.”
 Customer enters amount.
 System dispenses cash.
 System prints receipt.
 DEVELOPING USE CASES
 Jacobson suggests a number of questions that should be answered by a
use case:
 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?
 DEVELOPING USE CASES
Basic SafeHome requirements
 we define four actors:
 homeowner (a user),
 Setup manager (likely the same person as homeowner, but playing a different role),
 sensors (devices attached to the system),
 the monitoring and response subsystem (the central station that monitors the
SafeHome home security function).
 For the purposes of this example, we consider only the homeowner actor.
 The homeowner actor interacts with the home security function in a number of
different ways using either the alarm, control panel or a PC:
 Enters a password to allow all other interactions.
 Inquires about the status of a security zone.
 Inquires about the status of a sensor.
 Presses the panic button in an emergency.
 Activates/deactivates the security system.
DEVELOPING USE CASES
SafeHome Control Panel
 DEVELOPING USE CASES
Use Case: Initiate Monitoring
Considering the situation in which the homeowner uses the control panel,
the basic use case for system activation follows:
 The homeowner observes the SafeHome control panel to determine if the
system is ready for input.
 If the system is not ready, a not ready message is displayed on the LCD display.
 The homeowner uses the keypad to key in a four-digit password.
 The password is compared with the valid password stored in the system.
 If the password is incorrect, the control panel will beep once and reset itself for
additional input.
 If the password is correct, the control panel awaits further action.
 The homeowner select the keys in stay or away to activate the system.
 Stay activates only perimeter sensors (inside motion detecting sensors are
deactivated).
 Away activates all sensors.
 When activation occurs, a red alarm light can be observed by the
homeowner.
 Cockburn provides Detailed Description of Use Case:

USE CASE InitiateMonitoring

Primary actor Home Owner

To set the system to monitor sensors when the homeowner

Goal in context
leaves the house or remains inside

System has been programmed for a password and to

Preconditions:
recognize various sensors.

The homeowner decides to “set” the system, i.e., to turn

Trigger:
on the alarm functions
1. Homeowner: observes control panel
2. Homeowner: enters password
Scenario: 3. Homeowner: selects “stay” or “away”
4. Homeowner: observes read alarm light to indicate
that SafeHome has been armed
 1. Control panel is not ready: homeowner checks all sensors to
determine which are open; closes them.
2. Password is incorrect (control panel beeps once): homeowner
reenters correct password.
3. Password not recognized: monitoring and response subsystem
Exceptions: must be contacted to reprogram password.
4. Stay is selected: control panel beeps twice and a stay light
is lit; perimeter sensors are activated.
5. Away is selected: control panel beeps three times and an away
light is lit; all sensors are activated.
When available: First increment
Priority: Essential, must be implemented
Frequency of use: Many times, per day
Channel to actor Via control panel interface
Secondary actors: Support technician, sensors
Channels to 1. Support technician: phone line
secondary actors: 2. Sensors: hardwired and radio frequency interfaces

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?
Open issues: 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?
 DEVELOPING USE CASES
Use Case Diagram summarizing the Important scenarios of SafeHome home
security function
 BUILDING THE REQUIREMENT MODEL

 The intent of the analysis model is to provide a description of the required

informational, functional, and behavioral domains for a computer-based
system.
 The analysis model is a snapshot of requirements at any given time.

Elements of the Requirements Model

 The specific elements of the requirements model are dictated by the analysis
modeling method that is to be used.
 However, a set of generic elements is common to most requirements models.
 BUILDING THE REQUIREMENT MODEL
Elements of the Requirements Model
1. Scenario Based Elements: The system is described from the user’s point of view
using a scenario- based approach.
Ex: Use Case diagrams and Activity diagrams.

 Fig: UML activity diagrams for eliciting requirements

 BUILDING THE REQUIREMENT MODEL
Elements of the Requirements Model
2.Class-based Elements: Each usage scenario implies a set of objects that are manipulated
as an actor interacts with the system.
These objects are categorized into classes—a collection of things that have similar
attributes and common behaviors(operations).
Ex: Class diagram, Collaboration diagram.

Fig: Class diagram for sensor.

 BUILDING THE REQUIREMENT MODEL
Elements of the Requirements Model
 3. Behavioral Elements: In Software Engineering, the Behavioral
Elements Model is a concept used to describe the dynamic behavior of a
software system.
 It focuses on how the system's components interact with each other
and with external entities to achieve specific tasks or behaviors.
Ex: State diagram and Sequential Diagram.

Fig: UML state diagram notation

 BUILDING THE REQUIREMENT MODEL
Elements of the Requirements Model

4. Flow-Oriented elements: Information is transformed as it flows through

a computer- based system.
The system accepts input in a variety of forms, applies functions to transform
it, and produces output in a variety of forms.
Ex: Data-Flow diagram, Control Flow diagram.
 BUILDING THE REQUIREMENT MODEL
Analysis Patterns
 Analysis patterns suggest solutions within the application domain that can
be reused when modeling many applications.
 Geyer-Schulz and Hahsler suggest two benefits that can be associated with
the use of analysis patterns:
 First, analysis patterns speed up the development of abstract analysis
models that capture the main requirements of the concrete problem by
providing reusable analysis models with examples as well as a description of
advantages and limitations.
 Second, analysis patterns facilitate the transformation of the analysis model
into a design model by suggesting design patterns and reliable solutions for
common problems.
 NEGOTIATING REQUIREMENTS

 The intent of negotiation is to develop a project plan that meets stakeholder

needs while at the same time reflecting the real-world constraints (e.g., time,
people, budget) that have been placed on the software team.
 The best negotiations strive for a “win-win” result.
 That is, stakeholders win by getting the system or product that satisfies the majority of
their needs and you win by working to realistic and achievable budgets and deadlines.
 Boehm defines a set of negotiation activities at the beginning of each software
process iteration:
 Identification of the system or subsystem’s key stakeholders.
 Determination of the stakeholders’ “win conditions.”
 Negotiation of the stakeholders’ win conditions to reconcile them into a set of win-win
conditions for all concerned.
 Successful completion of these initial steps achieves a win-win result, which
becomes the key criterion for proceeding to subsequent software engineering
activities.
 VALIDATING REQUIREMENTS
 As each element of the requirements model is created, it is examined for inconsistency, omissions,
and ambiguity.
 A review of the requirements model addresses the following questions:
 Is each requirement consistent with the overall objectives 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?
 Is each requirement achievable in the technical environment that will house the system or product?
 Is each requirement testable, once implemented?
 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 requirements?
 These and other questions should be asked and answered to ensure that the requirements model is an
accurate reflection of stakeholder needs and that it provides a solid foundation for design.