SOFTWARE

ENGINEERING
Week6 : Requirements

Silva Matti | Software Engineering

Previously: A Generic Software Process Framework

General framework activities

11/7/21 2
Outline
• Requirements Engineering
• Req. Eng. tasks

11/7/21 3
Requirements Engineering
• The tasks and techniques that lead to an understanding of
requirements is called requirements engineering
• It is a major software engineering action that begins
during the communication activity and continues into the
modeling activity.
• It encompasses seven distinct tasks: inception, elicitation,
elaboration, negotiation, specification, validation, and
management. It is important to note that some of these
tasks occur in parallel and all are adapted to the needs of
the project.

11/7/21 4
Who Does It
• Software engineers (sometimes referred to as system
engineers or “analysts” in the IT world)
• and other project stakeholders (managers, customers,
end users) all participate in requirements engineering.

11/7/21 5
Why Req. Eng.
• Why is it important?
• Designing and building an elegant computer program that
solves the wrong problem serves no one’s needs. That’s
why it’s important to understand what the customer wants
before you begin to design and build a computer-based
system.

11/7/21 6
11/7/21 7
Req. Eng. Tasks (Quick map)
1. Inception— (identify: the problem, stakeholders, points of view, other
solutions..)
2. Elicitation— (Requirement gathering) elicit requirements from all
stakeholders
3. Elaboration—create an analysis model that identifies data, function and
behavioral requirements
4. Negotiation—agree on a deliverable system that is realistic for developers
and customers

11/7/21 8
Req. Eng. Tasks (Quick map)
5. Specification—can be any one (or more) of the following:
• A written document
• A set of models
• A formal mathematical
• A collection of user scenarios (use-cases)
• A prototype
6. Validation—a review mechanism that looks for
• errors in content or interpretation
• areas where clarification may be required
• missing information
• inconsistencies (a major problem when large products or systems are engineered)
• conflicting or unrealistic (unachievable) requirements.
7. Requirements management

11/7/21 9
Activity
• ONLINE ACTIVITY TIME

11/7/21 10
1. Inception
ask a set of questions that establish, basic understanding of the problem, the people
who want a solution, the nature of the solution that is desired, and the effectiveness of
preliminary communication and collaboration between the customer and the developer.

1. Identify stakeholders
• stakeholder is anyone who benefits in a direct or indirect way from
the system which is being developed. Ex: 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
• Create a list of stockholders (this might change with time). “who else
do you think I should talk to?”

11/7/21 11
1. Inception
2. Recognize multiple points of view

For example, the marketing group is interested in functions and

features that will excite the potential market, making the new
system easy to sell. Business managers are interested in a
feature set that can be built within budget and that will be ready
to meet defined market windows. End users may want features
that are familiar to them and that are easy to learn and use.
Software engineers may be concerned with functions that are
invisible to nontechnical stakeholders but that enable an
infrastructure that supports more marketable functions and
features. Support engineers may focus on the maintainability of
the software.
• Problem : information from multiple viewpoints is collected,
emerging requirements may be inconsistent or may conflict with
one another. Requirements should be consistent
11/7/21 12
1. Inception
3. Work toward collaboration: two ways
• Using “Priority Points”: Voting
• 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.
4. The first questions
• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful solution
• Is there another source for the solution that you need?

11/7/21 13
Eliciting Requirements
• also called requirements gathering
• More meetings are held with different stakeholders
• List of requirements is developed: there are three types of
requirements:
• Functional Requirements (Explicit): What the system should do,
objectives and goals, system functions and performance.
• Not-functional Requirements (implicit): The customer does not
explicitly state them. eg Security, privacy, accessibility, performance
etc…
• Constraints. How the system out to be developed e.g. Java,
waterfall, Eclipse, Windows etc...

*Explicit: stated clearly and in detail

*Implicit: not expressed directly
11/7/21 14
Eliciting Requirements
• the goal is
• to identify the problem
• propose elements of the solution
• negotiate different approaches, and
• specify a preliminary set of solution requirements

11/7/21 15
Work Products
• A statement of need.
• A bounded statement of scope for the system or product.
• a list of 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.
• 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

11/7/21 16
Req. Modeling | Use Cases
• Scenarios
• Diagrams
(Will be discussed later)

11/7/21 17
Negotiation
• Stakeholders are asked to balance Stakeholders need
(functionality, performance, and other product or system
characteristics) against real-world constraints (e.g., time,
people, budget).
• Requirements are eliminated, combined, and/or modified
so that each party achieves some measure of satisfaction
• “win-win” results for all.

11/7/21 18
SRS
• A software requirements specification (SRS) is a
document that is created when a detailed description of all
aspects of the software to be built must be specified
before the project is to commence.
• Not always needed.
• It is needed:
• when software is to be developed by a third party
• when a lack of specification would create severe business issues
• when a system is extremely complex or business critical
• See Software Requirements Specification Template file.

11/7/21 19
Validating Requirements
• elements of the requirements model is created are
examined for inconsistency, omissions, and ambiguity.
• The requirements are prioritized and grouped.

11/7/21 20
•Questions?
•Comments!
•Concerns..

11/7/21 21