SOFTWARE REQUIREMENT

ENGINEERING

.
 CHAPTER-1

Introduction to Software Requirements

Engineering
TABLE OF CONTENT:

 Definition
 Types of requirements
 Product vs project requirements
 Key players
 Requirement development & management
 Requirements Activities in the System Life Cycle
 Good practices for requirement engineering
 DEFINITION:

Requirements are a specification of what should be implemented. They are descriptions of how the system
should behave, or of a system property or attribute. They may be a constraint on the development
process of the system.

• Software requirements include three distinct levels: business requirements, user requirements, and
functional requirements. In addition, every system has an assortment of nonfunctional requirements.
 .

Types of Requirements

a) Business requirements describe why the organization is implementing the system—the business benefits
the organization hopes to achieve. The focus is on the business objectives of the organization or the
customer who requests the system.
b) User requirements describe goals or tasks the users must be able to perform with the product that will
provide value to someone. The domain of user requirements also includes descriptions of product
attributes or characteristics that are important to user satisfaction. Ideally, actual user representatives will
provide this information. User requirements describe what the user will be able to do with the system.
c) Functional requirements specify the behaviors the product will exhibit under specific conditions. They
describe what the developers must implement to enable users to accomplish their tasks (user
requirements), thereby satisfying the business requirements. This alignment among the three levels of
requirements is essential for project success.
 CONT...

The business analyst (BA)1 documents functional requirements in a software requirements specification
(SRS), which describes as fully as necessary the expected behavior of the software system.

d) Non-functional Requirements (NFRs) are intended to specify ‘system qualities,’ various systems attributes
that are not directly related to their functionality. These attributes do not tell what the system does but how
well it does it. In contrast, functional requirements are expressed as Capabilities, Features, and Stories,
which define what the system does in response to various inputs.
e) System requirements describe the requirements for a product that is composed of multiple components or
subsystems (ISO/IEC/IEEE 2011). A system can be all software or it can include both software and
hardware subsystems.
Product vs. Project requirements
.

• So far we have been discussing requirements that describe properties of a software system to be built. Let’s call those product
requirements.
• Projects certainly do have other expectations and deliverables that are not a part of the software the team implements, but that are
necessary to the successful completion of the project as a whole. These are project requirements but not product requirements.
Project requirements include:
• Physical resources the development team needs, such as workstations, special hardware, testing labs, testing tools and equipment.
• Staff training needs.
• Support documentation, such as help desk resources and field maintenance and service information for hardware devices.
• Requirements and procedures for releasing the product, installing it, configuring it, and testing the installation.
• Requirements and procedures for transitioning from an old system to a new one.
• Beta testing, manufacturing, packaging, marketing, and distribution requirements.
• Customer service-level agreements.
• Requirements for obtaining legal protection (patents, trademarks, or copyrights) for intellectual property related to the software.
Key Players
.

• A stakeholder is a person, group, or organization that is actively involved in a project, is affected by its
process or outcome, or can influence its process or outcome. Stakeholders can be internal or external to the
project team and to the developing organization.
• Customers are a subset of stakeholders. A customer is an individual or organization that derives either direct
or indirect benefit from a product. Software customers could request, pay for, select, specify, use, or receive
the output generated by a software product.
• The business analyst is the individual who has the primary responsibility to elicit, analyze, document, and
validate the needs of the project stakeholders. The analyst serves as the principal interpreter through which
requirements flow between the customer community and the software development team.
Business analyst include requirements analyst, systems analyst, requirements engineer, requirements manager,
application analyst, business systems analyst, IT business analyst, and simply analyst.
REQUIREMENTS DEVELOPMENT AND MANAGEMENT
 A REQUIREMENTS DEVELOPMENT
PROCESS FRAMEWORK

1. Elicitation
Elicitation encompasses all of the activities involved with discovering requirements, such as interviews,
workshops, document analysis, prototyping, and others.
The key actions are:
• Identifying the product’s expected user classes and other stakeholders.
• Understanding user tasks and goals and the business objectives with which those tasks align.
• Learning about the environment in which the new product will be used.
• Working with individuals who represent each user class to understand their functionality needs and their
quality expectations.
 .

2. Analysis
Analyzing requirements involves reaching a richer and more precise understanding of each requirement and
representing sets of requirements in multiple ways.

Following are the principal activities:

• Analyzing the information received from users to distinguish their task goals from functional requirements,
quality expectations, business rules, suggested solutions, and other information.
• Decomposing high-level requirements into an appropriate level of detail
• Deriving functional requirements from other requirements information
• Understanding the relative importance of quality attributes
• Allocating requirements to software components defined in the system architecture
• Negotiating implementation priorities
• Identifying gaps in requirements or unnecessary requirements as they relate to the defined scope
 .

3. Specification
Requirements specification involves representing and storing the collected requirements knowledge in a
persistent and well-organized fashion.

The principal activity is:

• Translating the collected user needs into written requirements and diagrams suitable for comprehension,
review, and use by their intended audiences.
 .

4. Validation
Requirements validation confirms that you have the correct set of requirements information that will enable
developers to build a solution that satisfies the business objectives.

The central activities are:

• Reviewing the documented requirements to correct any problems before the development group accepts them.
• Developing acceptance tests and criteria to confirm that a product based on the requirements would meet
customer needs and achieve the business objectives.
 REQUIREMENTS MANAGEMENT

Requirements management activities include the following:

• Defining the requirements baseline, a snapshot in time that represents an agreed-upon, reviewed, and approved set
of functional and non-functional requirements, often for a specific product release or development iteration
• Evaluating the impact of proposed requirements changes and incorporating approved changes into the project in a
controlled way
• Keeping project plans current with the requirements as they evolve
• Negotiating new commitments based on the estimated impact of requirements changes
• Working with individuals who represent each user class to understand their functionality needs and their quality
expectations.
• Defining the relationships and dependencies that exist between requirements
• Tracing individual requirements to their corresponding designs, source code, and tests
• Tracking requirements status and change activity throughout the project
 REQUIREMENTS ACTIVITIES IN THE SYSTEM LIFE CYCLE

Managers often think of requirements-related activities as consisting primarily of gathering requirements

and managing changes to those requirements throughout the life cycle. In reality, there are several other
requirements-related activities that need to be addressed in the system life cycle:
◗ Identifying the stakeholders: This includes anyone who has an interest in the system or in its possessing
qualities that meet particular needs.
◗ Gaining an understanding of the customers’ and users’ needs for the planned system and their expectations of
it: This is often referred to as requirements elicitation. Note that the requirements can include several types.
◗ Identifying requirements: This involves stating requirements in simple sentences and providing them as a set.
Business needs or requirements are the essential activities of an enterprise. They are derived from business goals
(the objectives of the enterprise). Business scenarios may be used as a technique for understanding business
requirements.
◗ Clarifying and restating the requirements: This is done to ensure that they describe the customer’s real needs
and are in a form that can be understood and used by developers of the system.
 CONTT…

◗ Defining the requirements in a way that means the same thing to all of the stakeholders: Note that each stakeholder group
may have a significantly different perspective of the system and the system’s requirements. Sometimes this requires
investing significant time learning a special vocabulary or project lexicon.
◗ Analyzing the requirements: This is done to ensure that they are well defined and that they conform to the criteria of a
good requirement.
◗ Specifying the requirements: This requires including all of the precise detail of each requirement so that it can be included
in a specification document or other documentation, depending on the size of the project.
◗ Prioritizing the requirements: All requirements are not of equal importance to the customers and users of the planned
system. Some are critical, some of relatively high priority, some of normal or average priority, and some even of lower
priority.
◗ Deriving requirements: There are some requirements that come about because of the design of a system, but do not
provide a direct benefit to the end user. A requirement for disc storage might result from the need to store a lot of data.
◗ Allocating requirements: We allocate requirements to different subsystems and components of the system. The allocations
may not always be satisfied by just one subsystem or component.
 CONTT….

◗ Tracking requirements: We need the capability to trace or track where in the system each requirement is satisfied, so that
we can verify that each requirement is being addressed. This is most often accomplished through use of an automated
requirements tool.
◗ Managing requirements: We need to be able to add, delete, and modify requirements during all of the phases of system
design, development, integration, testing, deployment, and operation. The requirements repository consists of a set of
artifacts and databases.
◗ Testing and verifying requirements: This is the process of checking requirements, designs, code, test plans, and system
products to ensure that the requirements are met.
◗ Validating requirements: This is the process for confirming that the real requirements are implemented in the delivered
system. The order of validation of requirements should be prioritized since there is a limited amount of funding available.
◗ Partitioning requirements: We categorize requirements as those that can be met by hardware, software, training, and
documentation, for example. Often this process turns out to be more complex than we anticipate when some requirements
are satisfied by more than one category.
GOOD PRACTICES FOR REQUIREMENT ENGINEERING

Good practices: Requirements elicitation

• Define product vision and project scope

• Identify user classes and their characteristics

• Conduct focus groups with typical users

• Work with user representatives to identify user requirements

• Identify system events and responses

• Hold elicitation interviews

• Hold facilitated elicitation workshops

• Distribute questionnaires

• Reuse existing requirements

• Perform document analysis

 CONTT…

Good practices: Requirements analysis

• Analyze requirement feasibility

• Prioritize the requirements
• Model the requirements
• Create a data dictionary
• Analyze interfaces between your system and the outside world
• Allocate requirements to subsystems
 CONTT…

Good practices: Requirements specification

• Adopt requirement document templates

• Identify requirement origins
• Uniquely label each requirement
• Record business rules
• Specify nonfunctional requirements
 CONTT…

Good practices: Requirements validation

• Review the requirements

• Test the requirements
• Define acceptance criteria
• Simulate the requirements
 CONTT…

Good practices: Requirements management

• Establish a requirements change control process

• Perform impact analysis on requirements changes
• Establish baselines and control versions of requirements sets
• Maintain a history of requirements changes
• Track the status of each requirement
• Track requirements issues
• Maintain a requirements traceability matrix
• Use a requirements management tool
 CONTT…

Good practices: Project management

• Select an appropriate software development life cycle

• Plan requirements approach
• Estimate requirements effort
• Base project plans on requirements
• Identify requirements decision makers
• Renegotiate project commitments when requirements change
• Analyze, document, and manage requirements-related risks
• Track the effort spent on requirements
• Review lessons learned regarding requirements on other projects
THANKS!