CSEN1131 - SOFTWARE ENGINEERING

UNIT-II
The Unified Process
✓ Evolved by Rumbaugh, Booch, and Jacobson.

✓ Combines the best features of their Object-Oriented models.

✓ Adopts additional features proposed by other experts.

✓ Resulted in Unified Modeling Language (UML).

✓ Unified process developed by Rumbaugh and Booch.

✓ A framework for Object-Oriented Software Engineering using UML.

Phases of Unified Process

✓ Inception phase

✓ Elaboration phase

✓ Construction phase

✓ Transition phase
✓ Production phase

Figure: The Unified Process Model

Tasks that are required to be completed during different phases
✓ Inception Phase
➢ Vision Document.
➢ Initial Use-Case Model.
➢ Initial Project Glossary.
➢ Initial Business Case.
➢ Initial Risk Assessment.
➢ Project Plan with phases and Iterations.
➢ Business Model.
✓ Elaboration Phase
➢ Use-Case model.
➢ Supplementary Requirements [Including non – functional].
➢ Analysis model.
➢ Software Architecture Description.
➢ Executable Architectural Prototype.
➢ Preliminary Design Model.
➢ Revised Risk List.
➢ Preliminary User Manual
➢ Project Plan [Iteration plan, Workflows, Milestones, Technical Work
Products]
✓ Construction Phase
➢ Design Model.
➢ System Components.
➢ Integrated Software Increment.
➢ Test plan and procedure.
➢ Test cases.
➢ Manuals [User, Installation, Current Increment].
✓ Transition Phase
➢ Delivered software increment
➢ Beta test results
➢ General user feedback
 Agility and Process
What is Agility?
✓ Agility is an effective response to change. It encourages team structures and attitudes
that make communication more facile (too easy).

✓ It emphasizes the rapid delivery of operational software.

✓ It adopts the customer as a part of the development team and recognizes that planning
has its limit and that a project plan must be flexible.

Agility and the Cost of Change

✓ The conventional wisdom in software development is that the cost of change increases
nonlinearly as a project progresses.

✓ It is relatively easy to accommodate a change when a software team is gathering

requirements.

✓ But if the team is in the middle of validation testing and an important stakeholder is
requesting a change.

✓ The time and cost required to ensure that the change is made without unintended side
effects are nontrivial.

✓ A well-designed agile process flattens the cost of the change curve, allowing a software
team to accommodate changes late in a software project without dramatic cost and time
impact.

What is an Agile Process?

Any agile software process is characterized in a manner that addresses a number of key
assumptions about the majority of software projects:
 ✓ 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. That is, both
activities should be performed in tandem so that design models are proven as they are
created. It is difficult to predict how much design is necessary before construction is
used to prove the design.
✓ Analysis, design, construction, and testing are not as predictable (from a planning point
of view) as we might like.
✓ An agile process, therefore, must be adaptable.
✓ But continual adaptation without forwarding progress accomplishes little. Therefore,
an agile software process must adapt incrementally. To accomplish incremental
adaptation, an agile team requires customer feedback.
Agile Principles
The Agile Alliance defines 12 principles for those software organizations that want to
achieve agility. These principles are summarized as follows below:
1. Our priority is to satisfy the customer through early and continuous delivery of valuable
software.

2. Welcome changing requirements.

3. Deliver working software frequently (weeks rather than months)

4. Businesspeople and developers must work together daily throughout the project.

5. Build Projects around motivated individuals. Give them the environment and support
they need and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation and daily cooperation between
businesspeople and developers.

7. Working software is the primary measure of progress.

8. Agile process promotes 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-organizing teams.
 12. At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.

Scrum
✓ Scrum is a very popular agile software development method that was conceived by Jeff
Sutherland and his development team in the early 1990s. Further development on the
Scrum methods was performed by Schwaber and Beedle.
✓ Scrum principles are consistent with the agile manifesto and are used to guide
development activities within a process that incorporates the following framework
activities: requirements, analysis, design, evolution, and delivery.
✓ Within each framework activity, work tasks take place in a relatively short time-boxed
period called a sprint.
✓ The work conducted within a sprint is adapted to the problem at hand and is defined
and often modified in real-time by the Scrum team.
✓ The number of sprints required for each framework activity will vary depending on the
size of the product and its complexity.
Scrum Teams and Artifacts
✓ The Scrum team is a self-organizing interdisciplinary team consisting of a product
owner, a Scrum master, and a small (three to six people) development team.
✓ The principle Scrum artifacts are the product backlog, the sprint backlog, and the code
increment.
✓ Development proceeds by breaking the project into a series of incremental prototype
development periods 2 to 4 weeks in length called sprints.
 Figure: The Scrum Process Flow

✓ The product backlog is a prioritized list of product requirements or features that

provide business value for the customer. Items can be added to the backlog at any time
with the approval of the product owner and the consent of the development team.
✓ The product owner orders the items in the product backlog to meet the most important
goals of all stakeholders. The product backlog is never complete while the product is
evolving to meet stakeholder needs. The product owner is the only person who decides
whether to end a sprint prematurely or extend the sprint if the increment is not accepted.
✓ The sprint backlog is the subset of product backlog items selected by the product team
to be completed as the code increment during the current active sprint.
✓ The increment is the union of all product backlog items completed in previous sprints
and all backlog items to be completed in the current sprints.
✓ The development team creates a plan for delivering a software increment containing
the selected features intended to meet an important goal as negotiated with the product
owner in the current sprint.
✓ Most sprints are time-boxed to be completed in 3 to 4 weeks. How the development
team completes the increment is left up to the team to decide.
 ✓ The development team also decides when the increment is done and ready to
demonstrate to the product owner. No new features can be added to the sprint backlog
unless the sprint is canceled and restarted.
✓ The Scrum master serves as a facilitator to all members of the Scrum team. She runs
the daily Scrum meeting and is responsible for removing obstacles identified by team
members during the meeting.
✓ She coaches the development team members to help each other complete sprint tasks
when they have time available. She helps the product owner find techniques for
managing the product backlog items and helps ensure those backlog items are stated in
clear and concise terms.
Sprint Planning Meetings
✓ The development team works with the product owner and all other stakeholders to
develop the items in the product backlog.
✓ Product owner and the development team rank the items in the product backlog by the
importance of the owner’s business needs and the complexity of the software
engineering tasks required to complete each.
✓ This results in the identification of missing features needed to deliver the required
functionality to the end users.
✓ Beforeto starting each sprint, the product owner states her development goal for the
increment to be completed in the upcoming sprint.
✓ Scrum master and development team select the items to move from to the sprint
backlog.
✓ Development team determines what can be delivered in the increment within the
constraints of the time-box allocated for the sprint and, with the Scrum master, what
work will be needed to deliver the increment.
✓ The development team decides which roles are needed and how they will need to be
filled.
Daily Scrum Meetings
✓ The daily Scrum meeting is a 15-minute event scheduled at the start of each workday
to allow team members to synchronize their activities and make plans for the next 24
hours.
✓ The Scrum master and the development team always attend the daily Scrum. Some
teams allow the product owner to attend occasionally.
✓ Three key questions are asked and answered by all team members:
 ➢ What did you do since the last team meeting?
➢ What obstacles are you encountering?
➢ What do you plan to accomplish by the next team meeting?
✓ The Scrum master leads the meeting and assesses the responses from each person. The
Scrum meeting helps the team to uncover potential problems as early as possible.
✓ It is the Scrum master’s task to clear obstacles presented before the next Scrum meeting
if possible.
✓ These are not problem-solving meetings; those occur off-line and only involve the
affected parties.
✓ These daily meetings lead to “knowledge socialization” and thereby promote a self-
organizing team structure.
✓ Some teams use these meetings to declare sprint backlog items complete or done. When
the team considers all sprint backlog items complete, the team may decide to schedule
a demo and review of the completed increment with the product owner.
Sprint Review Meetings
✓ The sprint review occurs at end of the sprint when the development team has judged
the increment complete.
✓ The sprint review is often time-boxed as a 4-hour meeting for a 4-week sprint. The
Scrum master, the development team, the product owner, and selected stakeholders
attend this review.
✓ The primary activity is a demo of the software increment completed during the sprint.
It is important to note that the demo may not contain all planned functionality, but rather
those functions that were to be delivered within the time box defined for the sprint.
✓ The product owner may accept the increment as complete or not. If it is not accepted,
the product owner and the stakeholders provide feedback to allow a new round of sprint
planning to take place.
✓ This is the time when new features may be added or removed from the product backlog.
The new features may affect the nature of the increment developed in the next sprint.
Sprint Retrospective
✓ Ideally, before beginning another sprint planning meeting, the Scrum master will
schedule a 3-hour meeting (for a 4-week sprint) with the development team called a
sprint retrospective.
✓ During this meeting the team discusses:
➢ What went well in the sprint?
 ➢ What could be improved?
➢ What the team will commit to improving in the next sprint?
✓ Scrum master leads the meeting and encourages the team to improve its development
practices to become effective for the next sprint. The team plans ways to improve
product quality by adapting its definition.
✓ At the end of the meeting, the team should have a good idea about the improvements
needed in the next sprint and be ready to plan the increment at the next sprint planning
meeting.
Requirements Engineering

• What are Requirements? Requirements are the features which have to feature in the
product or the problems which has to be solved to build the product.
• What is Requirement Engineering? It helps software engineers to better understand
the problem they will work to solve. It encompasses the set of tasks that lead to an
– understanding of what the business impact of the software will be,
– what the customer wants and
– how the end users will interact with the software.
• Who does it? Software engineers / system engineers/system Analysts/ requirements
engineer and stake holders (users, customers, end users, managers) all participate in the
requirement engineering.
• Why This? Designing and developing elegant working software which does not solve
the problem, is waste. So, requirement engineering is so important to better understand
the requirements which build good and functional software which solves the problem.
• Requirements engineering is the term for the broad spectrum of tasks and techniques
that lead to an understanding of requirements.
• From a software process perspective, requirements engineering is a major software
engineering action that begins during the communication activity and continues into the
modeling activity.
• Requirements engineering establishes a solid base for design and construction. Without
it, the resulting software has a high probability of not meeting customer’s needs.
• It must be adapted to the needs of the process, the project, the product, and the people
doing the work. It is important to realize that each of these tasks is done iteratively as
the project team and the stakeholders continue to share information about their
respective concerns.
 A Bridge to Design and Construction
• A good understanding of the requirements will give good idea how to solve the problem
or create quality software. If you have no idea what the customer is asking you end up
creating a wrong product or will be breaking the trust of the customer.
• Requirements engineering establishes a solid base for design and construction. Without
it, the resulting software or product has a high probability of not meeting the client’s /
customer’s needs. So, always the requirement engineering works as a bridge to design
and construction of good and quality software.
Requirement Engineering Tasks
• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Management
Inception
Inception encompasses both customer communication, planning activities.
• By collaborating with the customer and end-users,
– business requirements for the software are identifies,
– a rough architecture for the system is proposed, and
– a plan for the iterative, incremental nature of the ensuring project is developed.
• Its gives the scope of the project or the scope of the requirement based on the
communication done in the requirement gathering.
• Asking a set of questions that establish...
– Basic understanding of the problem.
– The people who want a solution.
– The nature of the solution is desired, and
– The effectiveness of preliminary communication and collaboration between the
customer and the developer.
Elicitation
 • Ask the customer, users and others what the objectives for the system or product, what
is to be accomplished, how the system or product is useful in day to day life, how it fits
into the business needs it looks simple but it’s hard.
• Identify number of problems that help us understand why requirements elicitation is
difficult
– Problem of scope – customers or users specify unnecessary technical details
that may confuse rather than clarify.
– Problem of understanding – customers or users are not completely sure of
what is needed, they don’t have full understanding of the problem domain.
– Problem of volatility – The requirements change over time
Elaboration
• Elaboration encompasses both planning and modeling. The information obtained from
the customer during inception and elicitation is expanded and refined during
elaboration.
• Elaboration is an analysis modeling action that is composed of a number of modeling
and refinement tasks.
• The end-result of an analysis model that defines information or data, functional and
behavioral domain of the problem.
Negotiation
• This is the task where the user’s /stakeholders/ customer’s come on to the same page
with the practitioners. Everybody will have the win- win situation. Agree on a
deliverable system that is realistic for developers and customers.
Specifications
• A specification can be written document, a set of graphical models, a formal
mathematical model, a collections of usage scenarios, a prototype or any combination
of these.
• The specification is final work product produced by the requirement engineer. It serves
as the foundation for subsequent software engineering activities. It describes the
function and performance of a computer-based system and constraints will govern its
development.
Validation
• The work products produced as a consequence of requirement engineering are assessed
for quality during a validation step.
• Requirements validation examines
 – the specification to ensure that all software requirements have been stated
unambiguously, inconsistencies, omissions, errors have been detected and
corrected
– the work products conform to the standards established for the process, project
and product.
• The primary requirements validation mechanism is the formal technical review (FTR)

Requirements Management
• Requirements Management is 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.
• Requirements Management begins with
– identification of requirements,
– once requirements have been identified,
– traceability tables are developed.
• Each traceability table relates requirements to one or more aspects of the system or its
environment.
• Among many possible traceability tables are follows.
– Features Traceability Table
– Source Traceability Table
– Dependency Traceability Table
– Subsystem Traceability Table
– Interface Traceability Table

Requirements gathering and Analysis

• Requirements gathering combines elements of problem solving, elaboration,
negotiation, and specification.
• 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
• Collaborative Requirements Gathering
• Usage Scenarios
• Elicitation Work products
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:
o Meetings (either real or virtual) are conducted and attended by both software
engineers and other stakeholders.
o Rules for preparation and participation are established.
o An agenda is suggested that is formal enough to cover all important points but
informal enough to encourage the free flow of ideas.
o A “facilitator” (can be a customer, a developer, or an outsider) controls the
meeting.
o A “definition mechanism” (can be work sheets, flip charts, or wall stickers or
an electronic bulletin board, chat room, or virtual forum) is used.
✓ The goal is
➢ To identify the problem.
➢ Propose elements of the solution.
➢ Negotiate different approaches, and
➢ Specify a preliminary set of solution requirements
✓ Many stakeholder concerns (e.g., accuracy, data accessibility, security) are the basis for
nonfunctional system requirements. As stakeholders enunciate these concerns, software
engineers must consider them within the context of the system to be built. The questions
that must be answered are:
➢ Can we build the system?
➢ Will this development process allow us to beat our competitors to
market?
➢ Do adequate resources exist to build and maintain the proposed system?
➢ Will the system performance meet the needs of our customers?

QFD [Quality Function Deployment]

This is a technique that translates the needs of the customer into technical requirements of the
software. It concentrates on maximizing the customer satisfaction from the software
engineering process. It identifies three types of requirements.
 ✓ Normal Requirements – identify 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 – are implicit to the product or system and may be so
fundamental that the customer does not explicitly state them. Their absence will be a
cause for significant dissatisfaction.
✓ Excited Requirements – go beyond the customer’s expectations and prove to be very
satisfying when present.

Many QFD concepts are applicable to the requirement elicitation activity.

✓ Function deployment determines the “value” (as perceived by 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 relative priority of requirements during each of the three
deployments.

Usage Scenarios

• Usage scenarios are nothing but the use cases which will provide how the system will
be used.
• As requirements are gathered, an overall vision of system functions and features begin
to materialize. However, it is difficult to move into more technical software engineering
activities until you understand how the 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.
Elicitation Work products

The Work products produced by the consequences of the requirement elicitation will vary
depending on the size of the system.

✓ 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)
✓ 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.

Agile Requirements Elicitation

• Within the context of an agile process, requirements are elicited by asking all
stakeholders to create user stories. Each user story describes a simple system
requirement written from the user’s perspective.
• User stories can be written on small note cards, making it easy for developers to select
and manage a subset of requirements to implement for the next product increment.
• Proponents claim that using note cards written in the user’s own language allows
developers to shift their focus to communication with stakeholders on the selected
requirements rather than their own agenda.
• Although the agile approach to requirements elicitation is attractive for many software
teams, critics argue that a consideration of overall business goals and nonfunctional
requirements is often lacking.
• In some cases, rework is required to accommodate performance and security issues. In
addition, user stories may not provide a sufficient basis for system evolution over time.
Service-Oriented Methods

• Service-oriented development views a system as an aggregation of services. A service

can be “as simple as providing a single function, for example, a request/response-based
mechanism that provides a series of random numbers, or can be an aggregation of
complex elements, such as the Web service API”.
• Requirements elicitation in service-oriented development focuses on the definition of
services to be rendered by an application.
• As a metaphor, consider the service provided when you visit a fine hotel. A doorperson
greets guests. A valet parks their cars. The desk clerk checks the guests in. A bellhop
manages the bags. The concierge assists guest with local arrangements. Each contact or
 touchpoint between a guest and a hotel employee is designed to enhance the hotel visit
and represents a service offered.
Requirements Analysis
• Requirements analysis results in the specification of software’s operational
characteristics, indicates software’s interface with other system elements, and
establishes constraints that software must meet.
• Requirements analysis allows you (regardless of whether you’re called a software
engineer, an analyst, or a modeler) to elaborate on basic requirements established
during the inception, elicitation, and negotiation tasks that are part of requirements
engineering.
• The requirements modeling action results in one or more of the following types of
models:
– Scenario-based models of requirements from the point of view of various
system “actors.”
– Class-oriented models that represent object-oriented classes (attributes and
operations) and how classes collaborate to achieve system requirements.
– Behavioral models that depict how the software reacts to internal or external
“events.”
– Data models that depict the information domain for the problem.
– Flow-oriented models that represent the functional elements of the system and
how they transform data as they move through the system.
• These models provide a software designer with information that can be translated to
architectural-, interface-, and component-level designs. Finally, the requirements model
(and the software requirements specification) provides the developer and the customer
with the means to assess quality once software is built.
Overall Objectives and Philosophy
• Throughout analysis modeling, your primary focus is on what, not how. What user
interaction occurs, what objects does the system manipulate, what functions must the
system perform, what behaviors does the system exhibit, what interfaces are defined,
and what constraints apply?
• The analysis model must achieve 3 primary objectives:
1. To describe what the customer requires
2. To establish a basis for the creation of a software design
3. To define a set of requirements that can be validated once the software is built.
 • The analysis model bridges the gap between a system-level description that describes
overall system or business functionality (software, hardware, data, human elements)
and a software design that describes the software’s application architecture, user
interface, and component-level structure. This relationship is illustrated in Figure.
• It is important to note that all elements of the requirements model will be directly
traceable to parts of the design model. A clear division between analysis and design
modeling tasks is not always possible. Some design invariably occurs as part of
analysis, and some analysis will be conducted during design.

Fig: The analysis model as a bridge between the system description and the design
model

Analysis Rules of Thumb

• The analysis model should focus on requirements that are visible within the problem or
business domain
– The level of abstraction should be relatively high
• Each element of the analysis model should add to an overall understanding of software
requirements and provide insight into the following
– Information domain, function, and behavior of the system
• The model should delay the consideration of infrastructure and other non-functional
models until the design phase
– First complete the analysis of the problem domain
• The model should minimize coupling throughout the system
– Reduce the level of interconnectedness among functions and classes
• The model should provide value to all stakeholders
• The model should be kept as simple as can be
******************************(OR)* ***(BEGIN)**********************
Requirements gathering and Analysis
• After an initial feasibility study, the next stage of the requirements engineering process
is requirements elicitation and analysis.
• In this activity, software engineers work with customers and system end-users to find
out about the application domain, what services the system should provide, the required
performance of the system, hardware constraints, and so on.

Fig: The requirements elicitation and analysis process

• Requirements elicitation and analysis may involve a variety of different kinds of people
in an organization.
• A system stakeholder is anyone who should have some direct or indirect influence on
the system requirements. Stakeholders include end users who will interact with the
system and anyone else in an organization who will be affected by it.
• Other system stakeholders might be engineers who are developing or maintaining other
related systems, business managers, domain experts, and trade union representatives.
• A process model of the elicitation and analysis process is shown in the above Figure.
• Each organization will have its own version or instantiation of this general model
depending on local factors such as the expertise of the staff, the type of system being
developed, the standards used, etc.
The process activities are:
1. Requirements discovery This is the process of interacting with stakeholders of the
system to discover their requirements. Domain requirements from stakeholders and
documentation are also discovered during this activity. There are several
complementary techniques that can be used for requirements discovery,
2. Requirements classification and organization This activity takes the unstructured
collection of requirements, groups related requirements, and organizes them into
coherent clusters. The most common way of grouping requirements is to use a model
of the system architecture to identify sub-systems and to associate requirements with
each sub-system. In practice, requirements engineering and architectural design cannot
be completely separate activities.
3. Requirements prioritization and negotiation Inevitably, when multiple stakeholders
are involved, requirements will conflict. This activity is concerned with prioritizing
requirements and finding and resolving requirements conflicts through negotiation.
Usually, stakeholders have to meet to resolve differences and agree on compromise
requirements.
4. Requirements specification The requirements are documented and input into the next
round of the spiral. Formal or informal requirements documents may be produced

• Eliciting and understanding requirements from system stakeholders is a difficult

process for several reasons:
1. Stakeholders often don’t know what they want from a computer system except in the
most general terms; they may find it difficult to articulate what they want the system to
do; they may make unrealistic demands because they don’t know what is and isn’t
feasible.
2. Stakeholders in a system naturally express requirements in their own terms and with
implicit knowledge of their own work. Requirements engineers, without experience in
the customer’s domain, may not understand these requirements.
3. Different stakeholders have different requirements and they may express these in
different ways. Requirements engineers have to discover all potential sources of
requirements and discover commonalities and conflict.
4. Political factors may influence the requirements of a system. Managers may demand
specific system requirements because these will allow them to increase their influence
in the organization.
5. The economic and business environment in which the analysis takes place is dynamic.
It inevitably changes during the analysis process. The importance of particular
requirements may change. New requirements may emerge from new stakeholders who
were not originally consulted.
Requirements discovery
• Requirements discovery (sometime called requirements elicitation) is the process of
gathering information about the required system and existing systems, and distilling
the user and system requirements from this information.
• Sources of information during the requirements discovery phase include
documentation, system stakeholders, and specifications of similar systems. You interact
with stakeholders through interviews and observation and you may use scenarios and
prototypes to help stakeholders understand what the system will be like.
• Stakeholders range from end-users of a system through managers to external stake-
holders such as regulators, who certify the acceptability of the system.
• For example, system stakeholders for the mental healthcare patient information
system include:
1. Patients whose information is recorded in the system.
2. Doctors who are responsible for assessing and treating patients.
3. Nurses who coordinate the consultations with doctors and administer some treatments.
4. Medical receptionists who manage patients’ appointments.
5. IT staff who are responsible for installing and maintaining the system.
6. A medical ethics manager who must ensure that the system meets current ethical
guidelines for patient care.
7. Healthcare managers who obtain management information from the system.
8. Medical records staff who are responsible for ensuring that system information can be
maintained and preserved, and that record keeping procedures have been properly
implemented.
• In addition to system stakeholders, we have already seen that requirements may also
come from the application domain and from other systems that interact with the system
being specified. All of these must be considered during the requirements elicitation
process.
Interviewing
• Formal or informal interviews with system stakeholders are part of most requirements
engineering processes. In these interviews, the requirements engineering team puts
questions to stakeholders about the system that they currently use and the system to be
developed. Requirements are derived from the answers to these questions.
Interviews may be of two types:
• 1. Closed interviews, where the stakeholder answers a pre-defined set of questions.
• 2. Open interviews, in which there is no pre-defined agenda. The requirements
engineering team explores a range of issues with system stakeholders and hence
develop a better understanding of their needs.
• In practice, interviews with stakeholders are normally a mixture of both of these. You
may have to obtain the answer to certain questions but these usually lead on to other
issues that are discussed in a less structured way.
• Completely open-ended discussions rarely work well. You usually have to ask some
questions to get started and to keep the interview focused on the system to be developed.
• Interviews are good for getting an overall understanding of what stakeholders do, how
they might interact with the new system, and the difficulties that they face with current
systems. People like talking about their work so are usually happy to get involved in
interviews. However, interviews are not so helpful in understanding the requirements
from the application domain.
• It can be difficult to elicit domain knowledge through interviews for two reasons:
1. All application specialists use terminology and jargon that are specific to a domain. It is
impossible for them to discuss domain requirements without using this terminology. They
normally use terminology in a precise and subtle way that is easy for requirements
engineers to misunderstand.
2. Some domain knowledge is so familiar to stakeholders that they either find it difficult to
explain or they think it is so fundamental that it isn’t worth mentioning. For example, for a
librarian, it goes without saying that all acquisitions are catalogued before they are added
to the library. However, this may not be obvious to the interviewer, and so it isn’t taken into
account in the requirements.
Effective interviewers have two characteristics:
1. They are open-minded, avoid pre-conceived ideas about the requirements, and are
willing to listen to stakeholders. If the stakeholder comes up with surprising requirements,
then they are willing to change their mind about the system.
2. They prompt the interviewee to get discussions going using a springboard question, a
requirements proposal, or by working together on a prototype system. Saying to people ‘tell
me what you want’ is unlikely to result in useful information. They find it much easier to
talk in a defined context rather than in general terms
Scenarios
• Scenarios can be particularly useful for adding detail to an outline requirements
description. They are descriptions of example interaction sessions. Each scenario
usually covers one or a small number of possible interactions.
• Different forms of scenarios are developed and they provide different types of
information at different levels of detail about the system.
• A scenario starts with an outline of the interaction. During the elicitation process, details
are added to this to create a complete description of that interaction. At its most general,
a scenario may include:
1. A description of what the system and users expects when the scenario starts.
2. A description of the normal flow of events in the scenario.
3. A description of what can go wrong and how this is handled.
4. Information about other activities that might be going on at the same time.
5. A description of the system state when the scenario finishes.
• Scenario-based elicitation involves working with stakeholders to identify scenarios and
to capture details to be included in these scenarios.
• Scenarios may be written as text, supplemented by diagrams, screen shots, etc.
Alternatively, a more structured approach such as event scenarios or use cases may be
used.
Use cases
• Use cases are a requirements discovery technique that were first introduced in the
Objectory method (Jacobson et al., 1993).
• They have now become a fundamental feature of the unified modeling language. In
their simplest form, a use case identifies the actors involved in an interaction and names
the type of interaction.
• This is then supplemented by additional information describing the interaction with the
system. The additional information may be a textual description or one or more
graphical models such as UML sequence or state charts.
• Use cases identify the individual interactions between the system and its users or other
systems. Each use case should be documented with a textual description. These can
then be linked to other models in the UML that will develop the scenario in more detail.
 Figure: Use cases for the MHC-PMS
• Scenarios and use cases are effective techniques for eliciting requirements from
stakeholders who interact directly with the system. Each type of interaction can be
represented as a use case. However, because they focus on interactions with the system,
they are not as effective for eliciting constraints or high-level business and non-
functional requirements or for discovering domain requirements.
Ethnography
• Ethnography is an observational technique that can be used to understand operational
processes and help derive support requirements for these processes.
• An analyst immerses himself or herself in the working environment where the system
will be used. The day-to-day work is observed and notes made of the actual tasks in
which participants are involved.
• The value of ethnography is that it helps discover implicit system requirements that
reflect the actual ways that people work, rather than the formal processes defined by
the organization.
 Figure: Ethnography and prototyping for requirements analysis

• Ethnography can be combined with prototyping as shown in above Figure. The

ethnography informs the development of the prototype so that fewer prototype
refinement cycles are required.
• Furthermore, the prototyping focuses the ethnography by identifying problems and
questions that can then be discussed with the ethnographer. He or she should then look
for the answers to these questions during the next phase of the system study
(Sommerville et al., 1993).
• Ethnographic studies can reveal critical process details that are often missed by other
requirements elicitation techniques. However, because of its focus on the end-user, this
approach is not always appropriate for discovering organizational or domain
requirements. They cannot always identify new features that should be added to a
system. Ethnography is not, therefore, a complete approach to elicitation on its own and
it should be used to complement other approaches, such as use case analysis.
• Ethnography is particularly effective for discovering two types of requirements:
1. Requirements that are derived from the way in which people actually work, rather than
the way in which process definitions say they ought to work.
For example, air traffic controllers may switch off a conflict alert system that detects aircraft
with intersecting flight paths, even though normal control procedures specify that it should
be used.
They deliberately put the aircraft on conflicting paths for a short time to help manage the
airspace. Their control strategy is designed to ensure that these aircrafts are moved apart
before problems occur and they find that the conflict alert alarm distracts them from their
work.
2. Requirements that are derived from cooperation and awareness of other people’s
activities.
For example, air traffic controllers may use an awareness of other controllers’ work to
predict the number of aircrafts that will be entering their control sector.
They then modify their control strategies depending on that predicted workload. Therefore,
an automated ATC system should allow controllers in a sector to have some visibility of
the work in adjacent sectors.
******************************(OR)****(END)*************************

Types of requirements
• The requirements of a system are the descriptions of the features or services that the
system exhibits within the specified constraints.
• The requirements collected from the customer are organized in some systematic manner
and presented in the formal document called software requirements specification (SRS)
document.
• Requirements engineering is the process of gathering, analyzing, documenting,
validating, and managing requirements.
• The main goal of requirements engineering is to clearly understand the customer
requirements and systematically organize these requirements in the SRS.
• A requirement is a detailed, formal description of system functionalities. It specifies a
function that a system or component must be able to perform for customer satisfaction.
• IEEE defines a requirement as:
• A condition or capability needed by a user to solve a problem or achieve an
objective (1)
• A condition or capability that must be met or possessed by a system or system
component to satisfy a contract, standard, specification or other formally
imposed documents (2)
• A documented representation of a condition or capability as in (1) and (2).
• The readers of the user requirements are not usually concerned with how the system
will be implemented and may be managers who are not interested in the detailed
facilities of the system.
• The readers of the system requirements need to know more precisely what the system
will do because they are concerned with how it will support the business processes or
because they are involved in the system implementation.

Figure: Readers of different types of requirements specification

• Software system requirements are often classified as functional requirements or non-
functional requirements:
1. Functional requirements These are statements of services the system should
provide, how the system should react to particular inputs, and how the system should
behave in particular situations. In some cases, the functional requirements may also
explicitly state what the system should not do.
2. Non-functional requirements These are constraints on the services or functions
offered by the system. They include timing constraints, constraints on the development
 process, and constraints imposed by standards. Non-functional requirements often
apply to the system as a whole, rather than individual system features or services.

Business Requirements:
• Understanding the business rules or the processes of organization is vital to software
development.
• Business requirements define the project goal and the expected business benefits for
doing the project.
• The enterprise mission, values, priorities, and strategies must be known to understand
the business requirements that cover higher level data models and scope of the models.
• The business analyst is well versed in understanding the concept of business flow as
well as the process being followed in the organization.
• The business analyst guides the client through the complex process that elicits the
requirements of their business.
User Requirements:
• User requirements are the high-level abstract statements supplied by the customer, end
users, or other stakeholders.
• These requirements are translated into system requirements keeping in mind user’s
views.
• These requirements are generally represented in some natural language with pictorial
representations or tables to understand the requirements.
• User requirements may be ambiguous or incomplete in description with less product
specification and little hardware/software configurations are stated in the user
requirements.
• There may be composite requirements with several complexities and confusions.
• In an ATM machine, user requirements allow users to withdraw and deposit cash.
System Requirements:
• System requirements are the detailed and technical functionalities written in a
systematic manner that are implemented in the business process to achieve the goal of
user requirements.
• These are considered as a contract between the client and the development organization.
• System requirements are often expressed as documents in a structured manner using
technical representations.
 • The system requirements consider customer ID, account type, bank name, consortium,
PIN, communication link, hardware, and software. Also, an ATM will service one
customer at a time.
Functional Requirements:
• Functional requirements are the behavior or functions that the system must support.
• These are the attributes that characterize what the software does to fulfill the needs of
the customer.
• These can be business rules, administrative tasks, transactions, cancellations,
authentication, authorization, external interfaces, legal or regulatory requirements,
audit tracking, certification, reporting requirements, and historical data.
Nonfunctional Requirements:
• Nonfunctional requirements specify how a system must behave. These are qualities,
standards, constraints upon the systems services that are specified with respect to a
product, organization, and external environment.
• Nonfunctional requirements are related to functional requirements, i.e., how efficiently,
by how much volume, how fast, at what quality, how safely, etc., a function is
performed by a particular system.
• The examples of nonfunctional requirements are reliability, maintainability,
performance, portability, flexibility, reusability, security, scalability, capacity,
availability, recoverability, serviceability, manageability, integrity, and interoperability.

Figure: Types of non-functional requirements

Non-Functional Requirements are classified into following types:

• Interface constraints
• Performance constraints: response time, security, storage space, etc.
• Operating constraints
• Life cycle constraints: maintainability, portability, etc.
• Economic constraints
Advantages of classifying software requirements include:
1. Better organization: Classifying software requirements helps organize them into
groups that are easier to manage, prioritize, and track throughout the development
process.
2. Improved communication: Clear classification of requirements makes it easier to
communicate them to stakeholders, developers, and other team members. It also
ensures that everyone is on the same page about what is required.
3. Increased quality: By classifying requirements, potential conflicts or gaps can be
identified early in the development process. This reduces the risk of errors, omissions,
or misunderstandings, leading to higher quality software.
4. Improved traceability: Classifying requirements helps establish traceability, which is
essential for demonstrating compliance with regulatory or quality standards.
Disadvantages of classifying software requirements include:
1. Complexity: Classifying software requirements can be complex, especially if there are
many stakeholders with different needs or requirements. It can also be time-consuming
to identify and classify all the requirements.
2. Rigid structure: A rigid classification structure may limit the ability to accommodate
changes or evolving needs during the development process. It can also lead to a siloed
approach that prevents the integration of new ideas or insights.
3. Misclassification: Misclassifying requirements can lead to errors or misunderstandings
that can be costly to correct later in the development process.