Requirement Engineering
Requirement Engineering
Types of Requirement
UserRequirements
User requirements are statements, in a natural language plus diagrams, of what services the system
is expected to provide and the constraints under which it must operate.
SystemRequirements
System requirements set out the system's functions, services and operational constraints in detail.
The system requirements document (sometimes called a functional specification) should be
precise. It should define exactly what is to be implemented. It may be part of the contract between
the system buyer and the software developers.(what,how?)
TypesOfSystemRe
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 sinlations.
In sOMie cases, the functional requirements may also explicitly state what the system should not do.
2. Non:functional requirements Thesc;: are constraints on the services or functions offered by the
system. They include tim~ng constraints, constraints on the development process and standards.
Non-funcltional requireme,nts often apply to the system as a whole. They do not usually just apply to
individual system features or services.
TypesOfNonfunctionalRequirements
The types of non-functional requirements are:
ProductRequrements These requirements specify product behaviour.
Examples include performance requirements on how fast the system must execute and how much
memory it requires; reliability requirements that set out the acceptable failure rate; portability
requirements; and usability requirements.
OrganisationalRequirements These requirements are derived from policies and procedures in the
customer s and developer s organisation. Examples include process standards that must be used;
implementation requirements such as the programming language or design method usedl; and
delivery requirements that spedfy when the product and :Its documentation are to be delivered.
ExternalRequirements This broad heading covers all requirements that are derived from factors
external to the system and its development process. These may include interoperability
requirements that define how the system interacts with systems in other organisations: legislative
requirements that must be followed to ensure that the system operates within the law; and ethical
requirements. Ethical requirements are requirements placed on a system to ensure that it will be
acceptable
to its users and the general public.
RequirementEngineeringProcess
It is a four-step process, which includes -
1. Feasibility Study:
The objective behind the feasibility study is to create the reasons for developing the software that is
acceptable to users, flexible to change and conformable to established standards.
Types of Feasibility:
Technical Feasibility - Technical feasibility evaluates the current technologies, which are needed to
accomplish customer requirements within the time and budget.
Operational Feasibility - Operational feasibility assesses the range in which the required software
performs a series of levels to solve business problems and customer requirements.
Economic Feasibility - Economic feasibility decides whether the necessary software can generate
financial profits for an organization.
RequirementsElicitationAndAnalysis
The process activities are:
1. Requirements discovery This is the process of interacting with stakeholders in the system to
collect their requirements. Domain requin:ments from stakeholders and documentation are also
discovered during this activity.
2. Requirements classijication and organisation This activity takes the unstructured collection of
requirements, groups related requirements and organises them into coherent clusters.
3. Requirements prioritisation and negotiation Inevitably, where multiple stakeholders are involved,
requirements will conflict. This a,ctivity is concerned with requirements, and finding and resolving
requirements conflicts through negotiation.
4. Requirements documentation The requirements are documented and input into the next round of
the spiral. Formal or informal requirements documents may be produced.