REQUIREMENTS SPECIFICATION

        
        REQUIREMENTS SPECIFICATION


REQUIREMENT SPECIFICATION



▪The process of writing the user and system requirements in a requirements document. 

▪ User requirements have to be understandable by end-users and customers who do not have a technical background. 

▪System requirements are more detailed requirements and may include more technical information. 

▪The requirements may be part of a contract for the system development 

▪ It is therefore important that these are as complete as possible.

REQUIREMENT AND DESIGN

▪In principle, requirements should state what the system should do and the design should describe how it does this. 

▪In practice, requirements and design are inseparable 

    

     ▪ A system architecture may be designed to structure the requirements; 

     ▪ The system may inter-operate with other systems that generate design requirements; 

     ▪ The use of a specific architecture to satisfy nonfunctional requirements may be a domain requirement. 

     ▪ This may be the consequence of a regulatory requirement.

NATURAL LANGUAGE SPECIFICATION

▪Requirements are written as natural language sentences supplemented by diagrams and tables. 

▪NL used for writing requirements because it is expressive, intuitive and universal. This means that the requirements  can be understood by clients, developers and customers.

PROBLEMS WITH NATURAL LANGUAGES

▪Lack of clarity 

        ▪ Precision is difficult without making the document difficult to read. 

▪Requirements confusion 

        ▪ Functional and non-functional requirements tend to be mixed-up. 

▪Requirements amalgamation 

       ▪ Several different requirements may be expressed together.

ALTERNATIVES FOR NATURAL LANGUAGES

1. Pseudo code 

             ▪ Requirements may be defined using a language like a programming language but with more flexibility of expression. Such a language is called pseudo code.

2.Graphical languages 

•                    

 3. Mathematical notation

                  

Representation of a finite-state machine; this example shows one that determines whether a binary number has an even number of 0s, where S1 is an accepting state.

structured specification

▪An approach to writing requirements where the freedom of the requirements writer is limited and requirements are written in a standard way. 

▪This works well for some types of requirements e.g. requirements for embedded control system but is sometimes too rigid for writing business system requirements.

from based specification

▪Definition of the function or entity. 

▪Description of inputs and where they come from. 

▪Description of outputs and where they go to. 

▪Information about the information needed for the computation and other entities used. 

▪Description of the action to be taken. 

▪Pre and post conditions (if appropriate). 

▪The side effects (if any) of the function.


Tabular specification


▪ Used to supplement natural language. 

▪ Particularly useful when you have to define a number of possible alternative courses of action. 

▪For example, the insulin pump systems bases its computations on the rate of change of blood sugar level and the tabular specification explains how to calculate the insulin requirement for different scenarios.

REQUIREMENTS CHANGE 

changing requirement

▪The business and technical environment of the system always changes after installation. 

▪New software, hardware may be introduced, it may be necessary to interface the system with other systems, business priorities may change (with consequent changes in the system support required), and new legislation and regulations may be introduced that the system must necessarily abide by. 

▪The people who pay for a system and the users of that system are rarely the same people. 

▪ System customers impose requirements because of organizational and budgetary constraints. These may conflict with enduser requirements and, after delivery, new features may have to be added for user support if the system is to meet its goals.

REQUIREMENT EVOLUTION

REQUIREMENT MANAGMENT

▪ Requirements management is the process of managing changing requirements during the requirements engineering process and system development. 

▪ New requirements emerge as a system is being developed and after it has gone into use. 

▪ You need to keep track of individual requirements and maintain links between dependent requirements so that you can assess the impact of requirements changes. You need to establish a formal process for making change proposals and linking these to system requirements.


REQUIREMENT MANAGEMENT PLANNING



▪ Establishes the level of requirements management detail that is required. 

▪ Requirements management decisions:

          ▪ Requirements identification Each requirement must be uniquely identified so that it can be cross-referenced with other requirements. 

         ▪ A change management process This is the set of activities that assess the impact and cost of changes. I discuss this process in more detail in the following section. 

         ▪ Traceability policiesThese policies define the relationships between each requirement and between the requirements and the system design that should be recorded. 

        ▪ Tool support Tools that may be used range from specialist requirements management systems to spreadsheets and simple database systems.

REQUIREMENT CHANGE MANAGMENT