UNIT-2 Reqmt Engg

Unit-3 : Requirement Engineering
• If a company wishes to let a contract for a large software

development project, it must define its needs in a
sufficiently abstract way that a solution is not predefined.
• The requirements must be written so that several
contractors can bid for the contract, offering, perhaps,
different ways of meeting the client organization’s needs.
• Once a contract has been awarded, the contractor must
write a system definition for the client in more detail so
that the client understands and can validate what the
software will do. Both of these documents may be called
the requirements document for the system.
Requirements in General
The term ‘user requirements’ to mean the high-
level abstract requirements and ‘system
requirements’ to mean the detailed description of
what the system should do. They are defined as
follows:
1.User requirements are statements, in a natural

language plus diagrams, of what services the
system is expected to provide to system users and
the constraints under which it must operate.
2.System requirements are more detailed

descriptions of the software system’s functions,
services, and operational constraints. The system
requirements document (sometimes called a
functional specification) should define exactly what
Example : Showing related requirements
Requirement Readers of the domain
Software Engg. Followed hierarchy:
Responsibilities of Requirement Readers
• In smaller projects, client's engineer is also responsible for
contracts and will be called an assistant project manager.
A similar role is also known as owner's engineer, but by
inference, often act more in the interests of the software
developer.
• Systems Architects divide large and complex systems into

manageable subsystems that can be handled by individual
engineers. ... Systems architects define the architecture of
a computerized system (i.e., a system composed of
software and hardware) in order to fulfill certain
requirements.
Requirements and Agile Methodology ?
Requirement Classification - based on Functionality
Software system requirements are often classified as

functional requirements or nonfunctional 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.
• The functional requirements for a system describe what
the system should do. These requirements depend on the
type of software being developed,
• When expressed as user requirements, functional

requirements are usually described in an abstract way
that can be understood by system users.
• More specifically functional requirements describe the

system required functions, like inputs and outputs,
exceptions, etc., in detail.
• Ideally, functional requirements of system specification

should be complete and consistent.
• Completeness means all user required services should be

defined. Consistency means requirements should not
have contradictory
• Non-functional requirements, as the name suggests, are
requirements that are not directly concerned with the
specific services delivered by the system to its users.
• Non-functional requirements, such as performance,
security, or availability, usually specify or constrain
characteristics of the system as a whole.
• Non-functional requirements are often more critical than
individual functional requirements.
• Failing to meet a non-functional requirement can mean
that the whole system is unusable.
• It is often possible to identify which system components
implement specific functional requirements. But it is often
more difficult to relate components to non-functional
requirements.
Example: to ensure that “performance” (non-functional)
requirements are met, we may have to organize the
system to minimize “communications” (Functional
requirement) between components.
It is preferable writing non-functional requirements
quantitatively. Accordingly the objectives can be tested
using following parameters,
The Requirements Document
• The requirements document is the official
statement of what is required of the system
developers.
• Should include both a definition of user

requirements and a specification of the system
requirements.
• It is NOT a design document. As far as possible,

it should set of WHAT the system should do
rather than HOW it should do it
IEEE -Requirements Standard
• Defines a generic structure for a
requirements document that must
be instantiated for each specific
system.
– Introduction.
– General description.
– Specific requirements.
– Appendices.
– Index.
Software Requirements Document
• The software requirements document (sometimes called
as the software requirements specification or SRS) is an
official statement of what the system developers should
implement.
• It should include both the user requirements for a
system and a detailed specification of the system
requirements.
• If there are a large number of requirements, the detailed
system requirements may be presented in a separate
document.
• The requirements document has a diverse set of users,
ranging from the senior management of the organization
that is paying for the system to the engineers
responsible for developing the software.
Software Requirements Document Users
Requirements document structure
• Preface
• Introduction
• Glossary
• User requirements definition
• System architecture
• System requirements specification
• System models
• System evolution
• Appendices
• Index

UNIT-2 Reqmt Engg

Uploaded by

Copyright:

Available Formats

UNIT-2 Reqmt Engg

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UNIT-2 Reqmt Engg

Uploaded by

Copyright:

Available Formats

Unit-3 : Requirement Engineering

• If a company wishes to let a contract for a large software

1.User requirements are statements, in a natural

2.System requirements are more detailed

• Systems Architects divide large and complex systems into

Software system requirements are often classified as

1.Functional requirements: These are statements of services the

2.Non-functional requirements: These are constraints on the services

• When expressed as user requirements, functional

• More specifically functional requirements describe the

• Ideally, functional requirements of system specification

• Completeness means all user required services should be

• Should include both a definition of user

• It is NOT a design document. As far as possible,

You might also like