0% found this document useful (0 votes)
18 views18 pages

Lec 5 Updated

The document outlines the software requirements engineering course offered at Air University, focusing on requirements analysis, prioritization, specification, validation, and management. It emphasizes the importance of clear communication among stakeholders and the use of various techniques and tools to ensure high-quality requirements. Additionally, it discusses the role of project management in effectively handling requirements throughout the software development lifecycle.

Uploaded by

Shamoil Zubair
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
18 views18 pages

Lec 5 Updated

The document outlines the software requirements engineering course offered at Air University, focusing on requirements analysis, prioritization, specification, validation, and management. It emphasizes the importance of clear communication among stakeholders and the use of various techniques and tools to ensure high-quality requirements. Additionally, it discusses the role of project management in effectively handling requirements throughout the software development lifecycle.

Uploaded by

Shamoil Zubair
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 18

SOFTWARE REQUIREMENTS ENGINEERING

BS Software Engineering
Semester, Spring 2025
Credit Hours 3

Instructor: Naseer Jan


Department of Creative Technologies
Air University
Islamabad, Pakistan

Department of Creative Technologies, Air University, Pakistan 1


Outline

Department of Creative Technologies, Air University, Pakistan 2


RE Analysis
Requirements analysis involves refining the requirements to ensure that all stakeholders understand them and
scrutinizing them for errors, omissions, and other deficiencies. Analysis includes decomposing high-level requirements
into appropriate levels of detail, building prototypes, evaluating feasibility, and negotiating priorities.
The goal is to develop requirements of sufficient quality and precision that managers can construct realistic project
estimates and technical staff can proceed with design, construction, and testing.
It is very valuable to represent some of the requirements in multiple ways—for example, in both textual and visual
forms, or in the forms of both requirements and tests.
These different views will reveal insights and problems that no single view can provide. Multiple views also help all
stakeholders arrive at a common understanding—a shared vision—of what they will have when the product is
delivered.

Model the application environment The context diagram is a simple analysis model that shows how the new system
fits into its environment. It defines the boundaries and interfaces between the system being developed and external
entities, such as users, hardware devices, and other systems. An ecosystem map shows the various systems in the
solution space that interact with each other and the nature of their interconnections.

3
RE Analysis
Create user interface and technical prototypes: When developers or users aren’t certain about the requirements,
construct a prototype—a partial, possible, or preliminary implementation—to make the concepts and possibilities more
tangible. Prototypes allow developers and users to achieve a mutual understanding of the problem being solved, as
well as helping to validate requirements.

Analyze requirement feasibility The BA should work with developers to evaluate the feasibility of implementing
each requirement at acceptable cost and performance in the intended operating environment. This allows stakeholders
to understand the risks associated with implementing each requirement, including conflicts and dependencies with
other requirements, dependencies on external factors, and technical obstacles. Requirements that are technically
infeasible or overly expensive to implement can perhaps be simplified and still contribute to achieving the project’s
business objectives.

Prioritize the requirements It’s important to prioritize requirements to ensure that the team implements the highest
value or most timely functionality first. Apply an analytical approach to determine the relative implementation priority
of product features, use cases, user stories, or functional requirements. Based on priority, determine which release or
increment will contain each feature or set of requirements. Adjust priorities throughout the project as new requirements
are proposed and as customer needs, market conditions, and business goals evolve.

4
RE Analysis
Create a data dictionary Definitions of the data items and structures associated with the system reside in the data
dictionary. This enables everyone working on the project to use consistent data definitions. As requirements are
developed, the data dictionary should define data items from the problem domain to facilitate communication between
the customers and the development team.

Model the requirements An analysis model is a diagram that depicts requirements visually, in contrast to the textual
representation of a list of functional requirements. Models can reveal incorrect, inconsistent, missing, and superfluous
requirements. Such models include data flow diagrams, entity relationship diagrams, state-transition diagrams, state
tables, dialog maps, decision trees, and others.

Analyze interfaces between your system and the outside world All software systems have connections to other
parts of the world through external interfaces. Information systems have user interfaces and often exchange data with
other software systems. Embedded systems involve interconnections between software and hardware components.
Network-connected applications have communication interfaces. Analyzing these helps make sure that your
application will fit smoothly into its environment.

5
RE Analysis
Allocate requirements to subsystems The requirements for a complex product that contains multiple subsystems
must be apportioned among the various software, hardware, and human subsystems and components. An example of
such a product is an access system to a secure building that includes magnetic or optical badges, scanners, video
cameras and recorders, door locks, and human guards

6
Requirements Prioritization

Requirements prioritization is as an activity in which the requirements are prioritized in terms of cost, value
and risk

• Requirement prioritization plays a key role in software development life cycle. The risk of software
failure is reduced up to greater extent with the help of requirements prioritization

• The most important requirements are identified with the help of requirements prioritization
Requirements Prioritization-Techniques

There are different requirements prioritization techniques for the prioritization of requirements.
Each technique usage and importance varies in various situation and area

• Analytic Hierarchy Process (AHP)


• Planning Game
• AHPcPG (AHP combined PG)
• Cumulative Voting or 100 Dollars
• EVOLVE
• Hierarchical Cumulative Voting (HCV)
• Binary Search tree (BST)
Requirements Specification
The essence of requirements specification is to document requirements of different types in a consistent, accessible, and
reviewable way that is readily understandable by the intended audiences.
You can record the business requirements in a vision and scope document. User requirements typically are represented
in the form of use cases or user stories. Detailed software functional and nonfunctional requirements are recorded in a
software requirements specification (SRS) or an alternative repository, such as a requirements management tool.

1. Adopt requirement document templates: Adopt standard templates for documenting requirements in your
organization, such as the vision and scope document template, the use case template, and the SRS template. The
templates provide a consistent structure for recording various groups of requirements-related information. Even if
you don’t store the requirements in traditional document form, the template will remind you of the various kinds of
requirements information to explore and record.

9
1.
Requirements Specification
Identify requirement origins To ensure that all stakeholders know why every requirement is needed, trace each one
back to its origin. This might be a use case or some other customer input, a high-level system requirement, or a
business rule. Recording the stakeholders who are affected by each requirement tells you whom to contact when a
change is requested. Requirement origins can be identified through traceability links or by defining a requirement
attribute for this purpose.
2. Uniquely label each requirement Define a convention for giving each requirement a unique identifying label. The
convention must be robust to withstand additions, deletions, and changes made in requirements over time.
3. Record business rules Business rules include corporate policies, government regulations, standards, and
computational algorithms. Document your business rules separately from a project’s requirements because they
typically have an existence beyond the scope of a specific project.
4. Specify nonfunctional requirements It’s possible to implement a solution that does exactly what it’s supposed to do
but does not satisfy the users’ quality expectations. To avoid that problem, you need to go beyond the functionality
discussion to understand the quality characteristics that are important to success.

10
Requirements Validation
1. Review the requirements: Peer review of requirements, particularly the type of rigorous review called inspection, is
one of the highest-value software quality practices. It is important to train the team members in how to perform
effective requirements reviews and to adopt a review process for your organization.
2. Test the requirements: Tests constitute an alternative view of the requirements. Writing tests requires you to think
about how to tell if the expected functionality was correctly implemented. Derive tests from the user requirements
to document the expected behavior of the product under specified conditions.
3. Define acceptance criteria: Ask users to describe how they will determine whether the solution meets their needs
and is fit for use. Acceptance criteria include a combination of the software passing a defined set of acceptance tests
based on user requirements, demonstrating satisfaction of specific non-functional requirements, and training in
place for a successful rollout.
4. Simulate the requirements Commercial tools are available that allow a project team to simulate a proposed system
either in place of or to augment written requirements specifications. Users can interact with the simulated system to
validate requirements and make design choices. Simulation is not a substitute for thoughtful requirements elicitation
and analysis, but it does provide a powerful supplement.

11
Requirements Management
1. Establish a requirements change control process Rather than stifling change or hoping changes don’t happen,
accept the fact that they will and establish a mechanism to prevent rampant changes from causing chaos. Charter a
small group of project stakeholders as a change control board (CCB) to evaluate proposed requirements changes,
decide which ones to accept, and set implementation priorities or target releases.
2. Perform impact analysis on requirements changes Impact analysis is an important element of the change process
that helps the CCB make informed business decisions. Evaluate each proposed requirement change to assess the
effect it will have on the project. Use the requirements traceability matrix to identify the other requirements, design
elements, source code, and tests that you might need to modify.
3. Establish baselines and control versions of requirements sets A baseline defines a set of agreed-upon requirements,
typically for a specific release or iteration. After the requirements have been baselined, changes should be made only
through the project’s change control process.
4. Maintain a history of requirements changes Retain a history of changes made to individual requirements. Record
the dates that requirements were changed, who made each change, and why. A version control tool or requirements
management tool can help with these tasks.

12
Requirements Management
5. Track the status of each requirement Establish a repository with one record for each discrete requirement of any
type that affects implementation. Store key attributes about each requirement, including its status (such as
proposed, approved, implemented, or verified), so you can monitor the number of requirements in each status
category at any time.
6. Track requirements issues When busy people are working on a complex project, it’s easy to lose sight of the many
issues that arise, including questions about requirements that need resolution, gaps to eradicate, and issues arising
from requirements reviews. Issue-tracking tools can keep these items from falling through the cracks.
7. Maintain a requirements traceability matrix It’s often valuable—and sometimes required—to assemble a set of links
that connect each functional requirement to the design and code elements that implement it and the tests that
verify it. Such a requirements traceability matrix is helpful for confirming that all requirements are implemented and
verified.
8. Use a requirements management tool Commercial requirements management tools let you store various types of
requirements in a database. Such tools help you implement and automate requirements management practices.

13
Knowledge
1. Use a requirements management tool: Commercial requirements management tools let you store various types of
requirements in a database. Such tools help you to automate many of the other requirements management
practices.
2. Educate stakeholders about requirements The most effective requirements training classes have an audience that
spans multiple project functional areas, not just BAs.
3. Educate developers about the application domain To help give developers a basic understanding of the application
domain, arrange a seminar on the customer’s business activities, terminology, and objectives for the product being
created. This can reduce confusion, miscommunication, and rework down the road.
4. Define a requirements engineering process Document the steps your organization follows to elicit, analyze, specify,
validate, and manage requirements. Providing guidance on how to perform the key steps will help analysts do a
consistently good job.
5. Create a glossary A glossary that defines specialized terms from the application domain will minimize
misunderstandings. Include synonyms, acronyms or abbreviations, terms that can have multiple meanings, and terms
that have both domain-specific and everyday meanings.

14
Project Management
1. Select an appropriate software development life cycle Your organization should define several development life
cycles that are appropriate for various types of projects and different degrees of requirements uncertainty). Each
project manager should select and adapt the life cycle that best suits her project.
2. Plan requirements approach Each project team should plan how it will handle its requirements development and
management activities. An elicitation plan helps ensure that you identify and obtain input from appropriate
stakeholders at the right stages of the project using the most appropriate techniques.
3. Estimate requirements effort Stakeholders often want to know how long it’s going to take to develop the
requirements for a project and what percentage of their total effort should be devoted to requirements development
and management.
4. Base project plans on requirements Develop plans and schedules for your project iteratively as the scope and
detailed requirements become clear. Begin by estimating the effort needed to develop the user requirements from
the initial product vision and project scope. Early cost and schedule estimates based on fuzzy requirements will be
highly uncertain, but you can improve the estimates as your understanding of the requirements improves.

15
Project Management
5. Identify requirements decision makers Software development involves making many decisions. Conflicting user
inputs must be resolved, commercial package components must be selected, change requests must be evaluated,
and so on..
6. Renegotiate project commitments when requirements change A project team makes commitments to deliver
specific sets of requirements within a particular schedule and budget. As you incorporate new requirements into the
project, evaluate whether you can still achieve the current commitments with the available resources.
7. Analyze, document, and manage requirements-related risks Unanticipated events and conditions can wreak havoc
on an unprepared project. Identify and document risks related to requirements as part of the project’s
risk-management activities. Brainstorm approaches to mitigate or prevent these risks, implement the mitigation
actions, and track their progress and effectiveness.
8. Track the effort spent on requirements To improve your ability to estimate the resources needed for requirements
work on future projects, record the effort your team expends on requirements development and management.
Monitor the effect that your requirements activities have on the project to help judge the return on your investment
in requirements

16
Questions

Questions and Answers sessions

Department of Creative Technologies, Air University, Pakistan 17


Department of Creative Technologies, Air University, Pakistan 18

You might also like