INTRODUCTION

Software
(1) instructions (computer programs) that when executed provide
desired features, function, and performance;
(2) data structures that enable the programs to adequately
manipulate information and
(3) documentation that describes the operation and use of the
programs.
Software Engineering
The application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of
A Generic Process Model
Process Flow
 Identifying a Task Set
• A task set defines the actual work to be done to accomplish the
objectives of a software engineering action.

– A list of the task to be accomplished

– A list of the work products to be produced

– A list of the quality assurance filters to be applied

 Process Patterns
• A process pattern
– describes a process-related problem that is encountered
during software engineering work,
– identifies the environment in which the problem has been
encountered, and
– suggests one or more proven solutions to the problem.

• A consistent method for describing problem solutions within

the context of the software process.
 Process Pattern Types
• Stage patterns—defines a problem associated with a
framework activity for the process.

• Task patterns—defines a problem associated with a software

engineering action or work task and relevant to successful
software engineering practice

• Phase patterns—define the sequence of framework activities

that occur with the process, even when the overall flow of
activities is iterative in nature.
 Process Assessment and Improvement
• Standard CMMI Assessment Method for Process Improvement (SCAMPI) — provides a
five step process assessment model that incorporates five phases:
– initiating,
– diagnosing,
– establishing,
– acting and
– learning.

• CMM-Based Appraisal for Internal Process Improvement (CBA IPI)

—provides a diagnostic technique for assessing the relative maturity of a
software organization; uses the SEI CMM as the basis for the assessment

• SPICE—The SPICE (ISO/IEC15504) standard defines a set of

requirements for software process assessment. The intent of the standard
is to assist organizations in developing an objective evaluation of the
efficacy of any defined software process.
 Prescriptive Models
• Prescriptive process models advocate an orderly approach
to software engineering
1. Waterfall or Classic Model
2. V – Model
3. Incremental Model
4. Evolutionary Model
1. Prototyping
2. Spiral
3. Concurrent
 The Waterfall Model or classic life cycle
model
• The waterfall model, sometimes called the classic life
cycle, suggests a systematic, sequential approach to
software development that begins with customer
specification of requirements and progresses through
– Communication
– planning,
– modeling,
– construction, and
– deployment,
• culminating in ongoing support of the completed
The Waterfall
Model
 The V-Model
• A variation in the representation of the waterfall model is called
the V-model
• depicts the relationship of quality assurance actions to the
actions associated with communication, modeling, and early
construction activities
• As a software team moves down the left side of the V, basic
problem requirements are refined into progressively more
detailed and technical representations of the problem and its
solution.
• Once code has been generated, the team moves up the right side
of the V, essentially performing a series of tests (quality
The V-Model
 Disadvantages of waterfall model
• Real projects rarely follow the sequential flow
that the model proposes
• It is often difficult for the customer to state all
requirements explicitly
• The customer must have patience. A working
version of the program(s) will not be available
until late in the project time span
 The Incremental Model
• The incremental model combines elements of
linear and parallel process flows
• The incremental model applies linear
sequences in a staggered fashion as calendar
time progresses.
• Each linear sequence produces deliverable
“increments” of the software in a manner that
is similar to the increments produced by an
The Incremental
Model
 Contd..
• When an incremental model is used, the first
increment is often a core product.
• As a result of use and/or evaluation, by a
customer a plan is developed for the next
increment
• This process is repeated following the delivery
of each increment, until the complete product
 Evolutionary Process models
• Evolutionary models are iterative.
• They are characterized in a manner that
enables to develop increasingly more
complete versions of the software.
• 2 types
– Prototyping
– The Spiral
 Evolutionary Models: Prototyping
• The prototyping paradigm begins with communication.

• You meet with other stakeholders to define the overall objectives for the
software, identify whatever requirements are known, and outline areas
where further definition is mandatory.

• A prototyping iteration is planned quickly, and modeling occurs.

• The quick design leads to the construction of a prototype.

• The prototype is deployed and evaluated by stakeholders, who provide

feedback that is used to further refine requirements.
Evolutionary Models:
Prototyping Quic
k
communicati plan
on
Modeling
Quick
design

Deployme Constructi
nt on
Constructi
delivery & ofon
feedback prototype
of
prototype
 Disadvantages
• As a stakeholder
– unaware that the prototype is held together
haphazardly, unaware that in the rush to get it working
you haven’t considered overall software quality or
long-term maintainability.
• As a software engineer
– make implementation compromises in order to get a
prototype working quickly
– inappropriate operating system or programming
language may be used
– an inefficient algorithm may be implemented
 Evolutionary Models: The Spiral
• The spiral development model is a risk-driven process model
generator that is used to guide multi-stakeholder concurrent
engineering of software intensive systems.

• It has two main distinguishing features.

– One is a cyclic approach for incrementally growing a
system’s degree of definition and implementation while
decreasing its degree of risk.
– The other is a set of anchor point milestones for ensuring
stakeholder commitment to feasible and mutually
 Contd..
• Using the spiral model, software is developed
in a series of evolutionary releases.
• During early iterations, the release might be a
model or prototype.
• During later iterations, increasingly more
complete versions of the engineered system
are produced.
Evolutionary Models: The
Spiral
• Advantages
– It can be adapted to apply throughout the life of the computer software
– The spiral model is a realistic approach to the development of large-
scale systems and software.
– It uses prototyping as a risk reduction mechanism
– It maintains the systematic stepwise approach suggested by the classic
life cycle but incorporates it into an iterative framework that more
realistically reflects the real world.
– It demands a direct consideration of technical risks at all stages of the
project and, if properly applied, should reduce risks before they
become problematic.

• Disadvantages
– It may be difficult to convince customers (particularly in contract
 Evolutionary Models: Concurrent
• The concurrent development model, sometimes called
concurrent engineering, allows a software team to
represent iterative and concurrent elements of any of
the process models
• The activity—modeling— may be in any one of the
states noted at any given time.
• Similarly, other activities, actions, or tasks (e.g.,
communication or construction) can be represented
 Contd..
For example
• early in a project the communication activity has
completed its first iteration and exists in the awaiting
changes state.
• The modeling activity which existed in the inactive
state while initial communication was completed, now
makes a transition into the under development state.
• If, however, the customer indicates that changes in
requirements must be made, the modeling activity
moves from the under development state into the
awaiting changes state.
Evolutionary Models: Concurrent
 What is “Agility”?
• Effective (rapid and adaptive) response to change
– Changes in software being built
– Changes to the team members
– Changes because of new technology
• Effective communication among all stakeholders
• Drawing the customer onto the team
• Organizing a team so that it is in control of the work performed
• An agile team recognizes that software is developed by
individuals working in teams and that the skills of these people,
their ability to collaborate is at the core for the success of the
project
Agility and the Cost of Change
•
Contd..
The conventional wisdom in software development (supported by
decades of experience) is that the cost of change increases
nonlinearly as a project progresses (Figure 3.1, solid black curve).
• Proponents of agility argue that a well-designed agile process
“flattens” the cost of change curve (Figure 3.1, shaded, solid
curve), allowing a software team to accommodate changes late in
a software project without dramatic cost and time impact.
• agile process encompasses incremental delivery.
• When incremental delivery is coupled with other agile practices
such as continuous unit testing and pair programming, the cost of
making a change is attenuated.
• Although debate about the degree to which the cost curve flattens
 An Agile Process
• KEY ASSUMPTIONS
– It is difficult to predict in advance which software
requirements will persist and which will change.
– It is equally difficult to predict how customer priorities will
change as the project proceeds.
– For many types of software, design and construction are
interleaved
– It is difficult to predict how much design is necessary before
construction is used to prove the design
• SOLUTION
– Agile process should be
 Contd..
• An incremental development strategy should be instituted.

• Software increments must be delivered in short time periods so

that adaptation keeps pace with change

• This iterative approach enables the customer

– to evaluate the software increment regularly,
– provide necessary feedback to the software team,
– and influence the process adaptations that are made to accommodate
the feedback
 Agility Principles (12)
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes

harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of

months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the
project.

5. Build projects around motivated individuals. Give them the environment

 Contd..
7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors,

developers, and users should be able to maintain a constant pace
indefinitely.

9. Continuous attention to technical excellence and good design enhances

agility.

10. Simplicity – the art of maximizing the amount of work not done – is
essential.

11. The best architectures, requirements, and designs emerge from self–
 Human Factors
• the process molds to the needs of the people and team, not the other way
around
• key traits must exist among the people on an agile team and the team itself:
– Competence
• encompasses innate talent, specific software-related skills, and
overall knowledge of the process that the team has chosen to apply
• Skill and knowledge taught to all agile team members
– Common focus
• Entire team should be focused on one goal—to deliver a working
software increment to the customer within the time promised.
• To achieve this goal, the team will also focus on continual
adaptations (small and large) that will make the process fit the
needs of the team.
– Collaboration.
Contd..
• team members must collaborate—with one another and all other stakeholders.
– Decision-making ability.
• The team is given autonomy—decision-making authority for both technical
and project issues.
– Fuzzy problem-solving ability
• agile team will continually have to deal with ambiguity and will continually be
buffeted by change
– Mutual trust and respect
• team exhibits the trust and respect that are necessary to make them “so
strongly knit that the whole is greater than the sum of the parts”.
– Self-organization
• Comprises three things:
(1) the agile team organizes itself for the work to be done,
 Extreme Programming (XP)
• Kent Beck defines a set of five values that establish a
foundation for all work performed as part of XP —
1) communication
2) simplicity
3) feedback
4) courage and
5) Respect

• Each of these values is used as a driver for specific XP

activities, actions, and tasks
 Extreme Programming (XP)
• The most widely used agile process, originally proposed by Kent
Beck
• XP Planning
– Begins with the creation of “user stories”
– Agile team assesses each story and assigns a cost
– Stories are grouped to for a deliverable increment
– A commitment is made on delivery date
– After the first increment “project velocity” is used to help
define subsequent delivery dates for other increments
 Contd..
1. Communication
– XP emphasizes close, yet informal (verbal) collaboration between
customers and developers,
– the establishment of effective metaphors for communicating important
concepts,
– continuous feedback and
– the avoidance of voluminous documentation as a communication
medium.
2. Simplicity
– XP restricts developers to design only for immediate needs, rather than
consider future needs.
– The intent is to create a simple design that can be easily implemented in
 Contd..
3. Feedback
Driven by 3 sources
1. implemented software itself,
2. customer and team members.
3. other software
– XP makes use of the unit test as its primary testing tactic
– use cases that are implemented by the increment are used as a basis for
acceptance tests.
– The degree to which the software implements the output, function, and
behavior of the use case is a form of feedback
– Finally, as new requirements are derived as part of iterative planning, the team
provides the customer with rapid feedback regarding cost and schedule impact.
4. Courage
– An agile XP team must have the discipline (courage)
 Contd..
5. Respect
• the agile team inculcates respect
– among it members,
– between other stakeholders and
– team members, and
– indirectly, for the software itself.

• As they achieve successful delivery of software increments, the team

develops growing respect for the XP process
•
XP Process
encompasses a set of rules and practices that occur within the context of four framework activities:
• planning
• design
• coding and
• Testing
• XP Planning
– It begins with listening
• a requirements gathering activity that enables the technical members of the XP team to
understand the business context for the software and to get a broad feel for required output and
major features and functionality
• The customer assigns a value
• assign a cost
– Commitment
• all stories will be implemented immediately (within a few weeks)
• the stories with highest value will be moved up in the schedule and implemented first,
• the riskiest stories will be moved up in the schedule and implemented first
– project velocity - number of customer stories implemented during the first release
• USES
 Contd..
• XP Design
– Follows the KIS (Keep It Simple) principle
• The design of extra functionality is discouraged
– Encourage the use of CRC cards (Class – Responsibility – Collaborator)
• identify and organize the object-oriented classes that are relevant to the
current software increment
• The CRC cards are the only design work product produced as part of the XP
process
– For difficult design problems, suggests the creation of “spike solutions”—a
design prototype is implemented and evaluated
– Encourages “refactoring”
• It is the process of changing a software system in such a way that it does not
alter the external behavior of the code yet improves the internal structure.
• It is a disciplined way to clean up code [and modify/simplify the internal
 Contd..
• XP Coding
– Recommends the construction of a unit test for a store before coding
commences
• Once the unit test has been created, the developer is better able to focus on
what must be implemented to pass the test
• Once the code is complete, it can be unit-tested immediately, thereby
providing instantaneous feedback to the developers
– Encourages “pair programming”
• XP recommends that two people work together at one computer
workstation to create code
• This provides a mechanism for real time problem solving and real-time
quality assurance
• the code they develop is integrated with the work of others (Sometimes on
daily basis)
• pair programmers have integration responsibility.
 Contd..
• XP Testing

• creation of unit tests before coding commences is a key element of the XP approach
• The unit tests that are created should be implemented using a framework
that enables them to be automated
• This encourages a regression testing strategy whenever code is modified
• the individual unit tests are organized into a “universal testing suite”
• integration and validation testing of the system can occur on a daily basis
• “Fixing small problems every few hours takes less time than fixing huge
problems just before the deadline.”

• “Acceptance tests” or “Customer tests” are defined by the customer and executed to
assess customer visible functionality
Extreme Programming (XP)
 Industrial XP (IXP)
• IXP is an organic evolution of XP.
• It is imbued with XP’s minimalist, customer-centric, test-driven spirit.
• IXP differs most from the original XP in its greater inclusion of
management, its expanded role for customers, and its upgraded technical
practices
• It has 6 new practices
1. Readiness assessment
2. Community
3. Project chartering
4. Test-driven management
5. Retrospectives
6. Continuous learning
Readiness assessment
The assessment ascertains whether
1. an appropriate development environment exists to support IXP,
2. the team will be populated by the proper set of stakeholders,
3. the organization has a distinct quality program and supports continuous
improvement,
4. the organizational culture will support the new values of an agile team, and
5. the broader project community will be populated appropriately.

Project community
• the right people be used to populate the agile team to ensure success
• team must be well-trained, adaptable and skilled, and have the proper temperament
to contribute to a self-organizing team
• Community - who “are often at the periphery of an IXP project yet they may play
important roles on the project
• the community members and their roles should be explicitly defined and
Project chartering
• The IXP team assesses the project itself to determine whether an appropriate
business justification for the project exists and
• whether the project will further the overall goals and objectives of the organization.
• Chartering also examines the context of the project to determine how it
– complements,
– extends, or
– replaces existing systems or
– processes.
Test-driven management
• Test-driven management establishes a series of measurable “destinations” and then
defines mechanisms for determining whether or not these destinations have been
reached.
Retrospectives - specialized technical review after a software increment is delivered
• the review examines “issues, events, and lessons-learned” across a software
increment and/or the entire software release
•
Contd..
Story-driven development (SDD) insists that stories for acceptance tests be written
before a single line of code is generated.
• Domain-driven design (DDD) is an improvement on the “system metaphor”
concept used in XP.
• the evolutionary creation of a domain model that “accurately represents how
• domain experts think about their subject”.
• Pairing extends the XP pair programming concept to include managers and other
stakeholders.
• The intent is to improve knowledge sharing among XP team members who may not
be directly involved in technical development.
• Iterative usability discourages front-loaded interface design in favor of usability
design that evolves as software increments are delivered and users’ interaction with
the software is studied
 XP Debate
• Requirements volatility
– customer is an active member of the XP team, changes to requirements are
requested informally
– the scope of the project can change and earlier work may have to be modified
to accommodate current needs
• Conflicting customer needs
– Many projects have multiple customers, each with his own set of needs.
– In XP, the team itself is tasked with assimilating the needs of different
customers, a job that may be beyond their scope of authority
• Requirements are expressed informally
– Critics argue that a more formal model or specification is often needed to
ensure that omissions, inconsistencies, and errors are uncovered before the
system is built.
– Proponents counter that the changing nature of requirements makes such
 Contd..
• Lack of formal design
– deemphasizes the need for architectural design
– suggests that design of all kinds should be relatively informal
– XP proponents suggest that the incremental nature of the XP process limits
complexity and
– therefore reduces the need for extensive design
 REQUIREMENT ENGINEERING
• REQUIREMENTS ENGINEERING
✓ major software engineering action that begins during the communication activity
and continues into the modeling activity. It must be adapted to the needs of the
process, the project, the product, and the people doing the work
✓ 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:
1. inception,
2. elicitation,
3. elaboration,
4. negotiation,
Inception
It establish
1. a basic understanding of the problem,
2. the people who want a solution,
3. the nature of the solution that is desired, and
4. the effectiveness of preliminary communication and collaboration between the
other stakeholders and
5. the software team
Elicitation
• It certainly seems simple enough—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
• Problems in elicitation
Contd…
1. 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
2. Problems of understanding
• have a poor understanding of the capabilities and limitations of their
computing environment
• have trouble communicating needs to the system engineer
• Omit information
3. Problems of volatility
• requirements change over time
Elaboration
• It is driven by the creation and refinement of user scenarios that describe how the end
user will interact with the system.
Negotiation
• customers and users to ask for more than can be achieved, given limited business resources
• Customers, users, and other stakeholders are asked to rank requirements and then discuss
conflicts in priority
• Using an iterative approach that
– prioritizes requirements,
– Assesses their cost and risk, and
– addresses internal conflicts,
– requirements are eliminated,
– combined,
– and/or modified so that each party achieves some measure of satisfaction
Specification
• A specification can be a
– Written document,
– a set of graphical models,
– a formal mathematical model,
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

Requirements management
• A set of activities that help the project team identify, control, and track
requirements and changes to requirements at any time as the project proceeds

• It is similar to Software Configuration Management (SCM) techniques

 ESTABLISHING THE GROUND REQUIREMENTS
Identifying Stakeholders
• stakeholder - “anyone 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,
 RECOGNIZING MULTIPLE VIEW POINTS

• Multiple viewpoints is collected, emerging requirements may

be inconsistent or may conflict with one another.

• We should categorize all stakeholder information (including

inconsistent and conflicting requirements) in a way that will
allow decision makers to choose an internally consistent set of
requirements for the system.
 Working toward collaboration
• job of a requirements engineer is to identify
– areas of commonality and
– areas of conflict or inconsistency

• 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
 Asking the first questions
• The first set of context-free questions focuses on the customer
and other stakeholders, the overall project goals and benefits
• These questions help to identify all stakeholders who will have
interest in the software to be built.
• In addition, the questions identify 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
 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
 Collaborative Requirements Gathering
• Basic guidelines
1. Meetings are conducted and attended by both software
engineers and other stakeholders.
2. Rules for preparation and participation are established.
3. An agenda is suggested that is formal enough to cover all
important points but informal enough to encourage the
free flow of ideas.
4. A “facilitator” (can be a customer, a developer, or an
outsider) controls the meeting.
5. A “definition mechanism” (can be work sheets, flip
 Contd…
• The goal is to identify the problem, propose elements of the
solution, negotiate different approaches, and specify a
preliminary set of solution requirements in an atmosphere that
is conducive to the accomplishment of the goal
• 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.
 Quality Function Deployment (QFD)
• It is a quality management technique that translates
the needs of the customer into technical requirements
for software.
• QFD “concentrates on maximizing customer
satisfaction from the software engineering process
• It identifies three types of requirements
1. Normal requirements
2. Expected 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.
 Contd…
Exciting Requirements
• These features go beyond the customer’s expectations and
prove to be very satisfying when present

• QFD uses customer interviews and observation, surveys, and

examination of historical data (e.g., problem reports) as raw data
for the requirements gathering activity

• These data are then translated into a table of requirements

Usage Scenarios
• 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.

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 (preferably organized by function) and the domain
constraints that apply to each.
 Developing Use Cases
• First step is to identify the Actors
• Actors are the different people (or devices) that use the system
or product within the context of the function and behavior that
is to be described.
• Actors represent the roles that people (or devices) play as the
system operates

• Primary actors interact to achieve required system function

and derive the intended benefit from the system.
• They work directly and frequently with the software.
Recalling basic SafeHome requirements, we define four actors:
1. homeowner (a user),
2. setup manager (likely the same person as homeowner, but playing a
different role),
3. sensors (devices attached to the system), and
4. the monitoring and response subsystem (the central station that monitors
the SafeHome home security function).

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.
 Template
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, i.e., to turn
on the alarm functions.
Scenario:
1. Homeowner: observes control panel
2. Homeowner: enters password
 Contd…
Exceptions:
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
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
 Contd…
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 radio frequency interfaces
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?
UML USE CASE DIAGRAM FOR SAFEHOME SECURITY
FUNCTION
 Building the requirements model
Elements of the requirements model
• Different modes of representation force you to consider
requirements from different viewpoints—an approach that has
a higher probability of uncovering omissions, inconsistencies,
and ambiguity

• Requirements model
1. Scenario based elements
2. Class based elements
3. Behavioral elements
Scenario based elements
Scenario-based elements of the requirements model are often the first part of
the model that is developed.
They serve as input for the creation of other modeling elements
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
Behavioral elements
• The behavior of a computer-based system can have a profound
effect on the design that is chosen and the implementation
approach that is applied.
• Therefore, the requirements model must provide modeling
elements that depict behavior.

State Diagram
• The state diagram is one method for representing the behavior
of a system by depicting its states and the events that cause the
system to change state.
UML STATE DIAGRAM NOTATION
 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.
• Input may be a
– control signal transmitted by a transducer,
– a series of numbers typed by a human operator,
– a packet of information transmitted on a network link, or
 Analysis Patterns
• These analysis patterns suggest solutions (e.g., a class, a
function, a behavior) within the application domain that can be
reused when modeling many applications.

• Analysis patterns are integrated into the analysis model by

reference to the pattern name.

• They are also stored in a repository so that requirements

engineers can use search facilities to find and apply them.
 NEGOTIATING REQUIREMENTS
• The intent of this 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.
• Following activities will be defined
1. Identification of the system or subsystem’s key
stakeholders.
2. Determination of the stakeholders’ “win conditions.”
3. Negotiation of the stakeholders’ win conditions to
 Validating Requirements
• As each element of the requirements model is created, it is examined for
inconsistency, omissions, and ambiguity.
• The requirements represented by the model are prioritized by the stakeholders and
grouped within requirements packages that will be implemented as software
increments.
• A review of the requirements model addresses the following questions:
1. Is each requirement consistent with the overall objectives for the
2. system/product?
3. Is the requirement really necessary or does it represent an add-on feature
4. that may not be essential to the objective of the system?
5. Is each requirement bounded and unambiguous?
6. Do any requirements conflict with other requirements?
7. Is each requirement achievable in the technical environment that will house
8. the system or product?