SYSTEM AND SOFTWARE REQUIREMENTS

SYSTEM AND SOFTWARE REQUIREMENTS

WHAT IS REQUIREMENT

▪ Descriptions and specifications of a system 

▪ It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. 

▪ This is inevitable as requirements may serve a dual function 

            ▪ May be the basis for a bid for a contract - therefore must be open to interpretation; 

           ▪ May be the basis for the contract itself - therefore must be defined in detail; 

           ▪ Both these statements may be called requirements.

WHAT IS REQUIREMENT ENGINEERING??

▪The process of establishing the services that a customer requires from a system and the constraints under which it operates and is developed. 

▪The system requirements are the descriptions of the system services and constraints that are generated during the requirements engineering process.

TYPES OF REQUIREMENT

▪ User requirements: High-level abstract requirements 

           ▪ Statements in a natural language plus diagrams of what services the system is expected to provide to system users and its operational constraints.

▪ System requirements: Detailed description of what the system should do 

          ▪ A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.

SYSTEM REQUIREMENT

▪More detailed descriptions of system functions, services and constraints than user requirements.

▪They are intended to be a basis for designing the system.

▪They may be incorporated into the system contract.

▪System requirements specification may include different models of the system. E.g. Object model, data-flow model.

SYSTEM STAKEHOLDERS

▪Any person or organization who is affected by the system in some way and so who has a legitimate interest 

▪Stakeholder types 

        ▪End users 

        ▪System managers 

        ▪System owners 

        ▪External stakeholders

REQUIREMENT ANALYSIS :WHY??

▪Many projects fail: 

       – Because they start  implementing the system without determining whether they are building what the customer really wants. 

▪It is important to learn Requirements analysis and specification techniques carefully.

REQUIREMENT VERIFIABILITY

▪Requirements should be written so that they can be objectively verified. 

▪see the following requirement statement;

                “The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized.”

What is wrong with this statement? 

“The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized.”

The problem with this requirement is its use of vague terms such as ‘ errors are minimized’

REQUIREMENT ENGINEERING

▪ Refers to the process of formulating, documenting and maintaining software requirements. 

▪Consists of four main phases 

       1. Feasibility (technical and otherwise) study 

       2. Requirements elicitation and analysis 

       3. Requirements specification (documentation) 

       4. Requirements validation

▪Feasibility Study 

▪A feasibility study is a short, focused study which aims to check the feasibility of the project considering resources, cost/benefit, technology availability etc. 

▪A feasibility study decides whether or not the proposed system is worthwhile. 

▪A short focused study that checks; 

         ▪ If the system contributes to organizational objectives 

         ▪ If the system can be engineered using current technology and within budget 

         ▪ If the system can be integrated with other systems that are used.

Requirement elicitation and analysis 

▪In this activity, technical software development staff work with customers and system end-users to find out about the application domain, what services the system should provide, the required performance of the system, hardware constraints and so on.

Requirements specification 

▪A detailed and precise description of the system requirements is set out to act as a basis for a contract between client and software developer.

Requirements validation 

▪In this activity, checks should be carried out to make sure that the requirements are accurate and complete. It is necessary to check the correctness of the specification of requirements.

READERS OF REQUIREMENT DOCUMENTS

                             

TYPES OF SOFTWARE REQUIREMENTS

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. 

Non-functional Requirements 

These are constraints on the services or functions offered by the system. 

Domain Requirements 

These are requirements that come from the application domain of the system and that reflect characteristics of the domain.

FUNCTIONAL REQUIREMENT


▪Describe functionality or services that the system is expected to provide.

▪Depend on the type of software, expected users and the type of system where the software is used.

▪Functional user requirements may be high-level statements of what the system should do but functional system requirements should describe the system services in detail.


NON FUNCTIONAL REQUIREMENT



▪These define system properties and constraints

▪ System Properties : reliability, response time and store occupancy.

▪ Constraints : I/O device capability, data representations used in system interfaces.

▪More critical than functional requirements. If these are not met, the system is useless.

▪Relate to the system as a whole rather than to individual system features.

▪Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify. 

▪May be written to reflect the goals of the customer. 

▪Goal 

       ▪ A general intention of the user such as ease of use. 

       ▪ Goals are helpful to developers as they convey the intentions of the system users.

NON FUNCTIONAL REQUIREMENT CLASSIFICATION

1. Product Requirements 

▪Requirements which specify that the delivered product must behave in a particular way. 

▪ Performance requirements 

▪ Reliability 

▪ Portability 

▪ Interface requirements 

2. Organizational Requirements 

▪Requirements which are a consequence of organizational policies and procedures like process standards used and implementation requirements.

▪ Delivery requirements
▪ Implementation requirements
▪ Standards requirements

3. External Requirements

▪Requirements which arise from factors which are external to the system and its development process such as interoperability requirements, legislative requirements etc.

▪ Interoperability requirements
▪ Ethical requirements
▪ safety requirements


DOMAIN REQUIREMENT

▪ The global objective of Domain Requirements Description activity is to provide an overview of the system’s context and capabilities. This activity aims thus at gathering needs and expectations of the application’s stakeholders and provide a complete .

▪The system’s operational domain imposes requirements on the system.

▪ For example, a train control system has to take into account the braking characteristics in different weather conditions.

▪Domain requirements can be new functional requirements, constraints on existing requirements or define specific computations.


REQUIREMENT ENGINEERING PROCESS


▪ The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.

▪ However, there are a number of generic activities common to all processes

▪ Requirements elicitation;
▪ Requirements analysis;
▪ Requirements validation;
▪ Requirements management.

▪ In practice, RE is an iterative activity in which these processes are interleaved.