Requirements engineering

Requirements Engineering : Requirements Engineering 1 Requirements Engineering - A Study

Definition : Requirements Engineering 2 Definition The process of establishing the services the system should provide and the constraints under which it must operate is called requirements engineering. The purpose is to establish the specification which are correct, consistent and free of all errors.

Slide 3 : Requirements Specification 3

Stages of Requirements Engineering : Requirements Engineering 4 Stages of Requirements Engineering Feasibility Study- An estimate is made of whether the identified user needs may be satisfied using current hardware and software technology. Requirement Analysis-This is the process of deriving the system requirements through observation of existing system ,discussion with users and task analysis Requirements Definition- Requirements definition is the activity of translating the information gathered during the analysis activity into a document that defines a set of requirements . Requirements Specification-A detailed and precise description of the system requirements is set out to act as a basis of the contract between the client and the software developer Requirements Validation- It is a means of testing the requirements for their correctness, consistensy and evoution

Slide 5 : Feasibbility Study 5

Slide 6 : Feasibility Study 6

Requirement Analysis : Requirements Analysis 7 Requirement Analysis Domain Understanding Requirements Collection Classification Conflict Resolution Prioritization Requirements Validation

Viewpoint Analysis : Requirements Analysis 8 Viewpoint Analysis Requirements Viewpoint Viewpoint Viewpoint Viewpoint

System Context Analysis An Example : Requirements Analysis 9 System Context Analysis An Example Auto-teller System Security System Maintenance System Branch Counter System Branch Accounting System Accounts Database Usage Database

Requirements Specification : Requirements Specification 10 Requirements Specification Requirements Specification- a) Structured Natural Language b) Design Description Language c) Requirements Specification Language d) Graphical Notation e) Mathematical Specification

Structure of requirements document : Requirements Specification 11 Structure of requirements document Introduction System Models Functional requirements definition Non-functional requirements definition System evolution Requirements Specification

Software Prototyping : Requirements Specification 12 Software Prototyping Outline Requirements Outline Requirements Outline Requirements Evolutionary Prototype Throwaway Prototype

Prototyping using 4GL : Requirements Specification 13 Prototyping using 4GL Simplest 4GL’s are the database query languages such as SQL. 4GL’s may also contain packages like report genarator,screen form design to provide interactive facility.

Formal Specification : Requirements Specification 14 Formal Specification A formal specification is a specification expressed in a language where vocabulary ,syntax and semantic are formally defined. These languages are based on mathematics Example- Function search(X:Integer_Array, key:Integer) Return Integer Pre: exists i in X_first..X_Last Post: Search(X,key)==1

Slide 15 : Requirements Specification 15

Slide 16 : Requirements Specification 16

Algebraic Specification : Requirements Specification 17 Algebraic Specification It involves specification structure, operator selection, syntax definition and axiom definition. Example- a,b,c : Integers a,b,c: a>b,a=b,a>c a,b,c: a=b.c,a=b+c

Structured Specification : Requirements Specification 18 Structured Specification Define the variables- X,Key,I Define the purpose- The function searches for a key in a given list of integers. Define the Functions – Search(List,Key)

Slide 19 : Requirements Validation 19

Slide 20 : Requirements Validation 20

Slide 21 : Requirements Validation 21

Validation inputs and outputs : Requirements Specification 22 Validation inputs and outputs

Requirements review process : Requirements Specification 23 Requirements review process

Review team membership : Requirements Specification 24 Review team membership Reviews should involve a number of stakeholders drawn from different backgrounds People from different backgrounds bring different skills and knowledge to the review Stakeholders feel involved in the RE process and develop an understanding of the needs of other stakeholders Review team should always involve at least a domain expert and an end-user

Review checklists : Requirements Specification 25 Review checklists Understandability Can readers of the document understand what the requirements mean? Redundancy Is information unnecessarily repeated in the requirements document? Completeness Does the checker know of any missing requirements or is there any information missing from individual requirement descriptions? Ambiguity Are the requirements expressed using terms which are clearly defined? Could readers from different backgrounds make different interpretations of the requirements?

Review checklists : Requirements Specification 26 Review checklists Consistency Do the descriptions of different requirements include contradictions? Are there contradictions between individual requirements and overall system requirements? Organisation Is the document structured in a sensible way? Are the descriptions of requirements organised so that related requirements are grouped? Conformance to standards Does the requirements document and individual requirements conform to defined standards? Are departures from the standards, justified? Traceability Are requirements unambiguously identified, include links to related requirements and to the reasons why these requirements have been included?

Prototyping for validation : Requirements Specification 27 Prototyping for validation

User manual development : Requirements Specification 28 User manual development Writing a user manual from the requirements forces a detailed requirements analysis and thus can reveal problems with the document Information in the user manual Description of the functionality and how it is implemented Which parts of the system have not been implemented How to get out of trouble How to install and get started with the system

Model validation : Requirements Specification 29 Model validation Validation of system models is an essential part of the validation process Objectives of model validation To demonstrate that each model is self-consistent If there are several models of the system, to demonstrate that these are internally and externally consistent To demonstrate that the models accurately reflect the real requirements of system stakeholders Some checking is possible with automated tools Paraphrasing the model is an effective checking technique

Data-flow diagram for Issue : Requirements Specification 30 Data-flow diagram for Issue

Requirements testing : Requirements Specification 31 Requirements testing Each requirement should be testable i.e. it should be possible to define tests to check whether or not that requirement has been met. Inventing requirements tests is an effective validation technique as missing or ambiguous information in the requirements description may make it difficult to formulate tests Each functional requirement should have an associated test

Test case definition : Requirements Specification 32 Test case definition What usage scenario might be used to check the requirement? Does the requirement, on its own, include enough information to allow a test to be defined? Is it possible to test the requirement using a single test or are multiple test cases required? Could the requirement be re-stated to make the test cases more obvious?

Test record form : Requirements Specification 33 Test record form The requirement’s identifier There should be at least one for each requirement. Related requirements These should be referenced as the test may also be relevant to these requirements. Test description A brief description of the test and why this is an objective requirements test. This should include system inputs and corresponding outputs. Requirements problems A description of problems which made test definition difficult or impossible. Comments and recommendations These are advice on how to solve requirements problems which have been discovered.

Requirements test form : Requirements Specification 34 Requirements test form

Hard-to-test requirements : Requirements Specification 35 Hard-to-test requirements System requirements Requirements which apply to the system as a whole. In general, these are the most difficult requirements to validate irrespective of the method used as they may be influenced by any of the functional requirements. Tests, which are not executed, cannot test for non-functional system-wide characteristics such as usability. Exclusive requirements These are requirements which exclude specific behaviour. For example, a requirement may state that system failures must never corrupt the system database. It is not possible to test such a requirement exhaustively. Some non-functional requirements Some non-functional requirements, such as reliability requirements, can only be tested with a large test set. Designing this test set does not help with requirements validation.

Key points : Requirements Specification 36 Key points Requirements validation should focus on checking the final draft of the requirements document for conflicts, omissions and deviations from standards. Inputs to the validation process are the requirements document, organisational standards and implicit organisational knowledge. The outputs are a list of requirements problems and agreed actions to address these problems. Reviews involve a group of people making a detailed analysis of the requirements. Review costs can be reduced by checking the requirements before the review for deviations from organisational standards. These may result from more serious requirements problems.

Key points : Requirements Specification 37 Key points Checklists of what to look for may be used to drive a requirements review process. Prototyping is effective for requirements validation if a prototype has been developed during the requirements elicitation stage. Systems models may be validated by paraphrasing them. This means that they are systematically translated into a natural language description. Designing tests for requirements can reveal problems with the requirements. If the requirement is unclear, it may be impossible to define a test for it.

Slide 38 : Requirements Validation 38

Slide 39 : Requirements Validation 39