ELICITATION AND ANALYSIS OF REQUIREMENTS

             ELICITATION AND ANALYSIS OF REQUIREMENTS

REQUIREMENT ELICITATION AND ANALYSIS

▪Sometimes called requirements elicitation or requirements discovery. 

▪Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints. 

▪May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. They are called stakeholders.

▪Software engineers work with a range of system stakeholders to find out about the application domain, the services that the system should provide, the required system performance, hardware constraints, other systems, etc. 

▪Stages include: 

▪ Requirements discovery, 
▪ Requirements classification and organization, 
▪ Requirements prioritization and negotiation, 
▪ Requirements specification.

REQUIREMENT ELICITATION AND ANALYSIS PROCESS





PROCESS ACTIVITIES



1. Requirements discovery 

               ▪ Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage. 

2. Requirements classification and organization 

             ▪ Groups related requirements and organizes them into coherent clusters. 

3. Prioritization and negotiation 

            ▪ Prioritizing requirements and resolving requirements conflicts. 

4. Requirements specification 

          ▪ Requirements are documented and input into the next round of the spiral.

PROBLEMS OF REQUIREMENT ELICITATION

▪ Stakeholders don’t know what they really want. 

▪ Stakeholders express requirements in their own terms. 

▪ Different stakeholders may have conflicting requirements. 

▪ Organizational and political factors may influence the system requirements. 

▪ The requirements change during the analysis process. 

▪ New stakeholders may emerge and the business environment change.

REQUIREMENT ANALYSIS TOOLS

▪Traditional structured methods 

▪Entity relationship diagrams (ERD) 

▪Data Flow Diagrams (DFDs) 

▪Entity State Transition diagrams 

▪Object Oriented methods (O-O) 

▪Use Case Diagrams 

▪Class Diagrams 

▪Sequence Diagrams 

▪State Transition Diagrams

REQUIREMENTS DISCOVERY

▪The process of gathering information about the required and existing systems and distilling the user and system requirements from this information. 

▪ Interaction is with system stakeholders from managers to external regulators. 

▪Systems normally have a range of stakeholders.

USE CASES

▪Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself. 

▪A set of use cases should describe all possible interactions with the system. 

▪High-level graphical model supplemented by more detailed tabular description. 

▪Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.

REFINING USECASE DIAGRAM

▪ Once the initial use-cases have been documented they can be refined 

▪ The refining of a Use-Case diagram can help simplify and remove unnecessary redundancy 

▪ There are three main ways in which refinement can be performed (usually aided by reading descriptions, see later) 

▪ Identification of shared sequences of operations (include) 

▪ Identification of alternative actions within single use-cases (extend) 

▪ Identification of common behaviour between use-cases (inheritance).

REQUIREMENTS VALIDATION

▪Concerned with demonstrating that the requirements define the system that the customer really wants. 

▪Requirements error costs are high so validation is very important 

▪ Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.

REQUIREMENT CHECKING

▪Validity: Does the system provide the functions which best support the customer’s needs? 

▪ Consistency: Are there any requirements conflicts? 

▪ Completeness: Are all functions required by the customer included? 

▪ Realism: Can the requirements be implemented given available budget and technology? 

▪ Verifiability: Can the requirements be checked?

REQUIREMENT VALIDATION TECHNIQUES

▪Requirements reviews 

         ▪Systematic manual analysis of the requirements. 

▪Prototyping 

        ▪Using an executable model of the system to check requirements. 

▪Test-case generation 

       ▪Developing tests for requirements to check testability.

REQUIREMENT REVIEWS

▪Regular reviews should be held while the requirements definition is being formulated. 

▪Both client and contractor staff should be involved in reviews. 

▪Reviews may be formal (with completed documents) or informal.

 ▪Good communications between developers, customers and users can resolve problems at an early stage.

▪ Review Checks; 

      ▪ Verifiability 

            ▪ Is the requirement realistically testable? 

     ▪ Comprehensibility 

           ▪ Is the requirement properly understood? 

     ▪ Traceability 

          ▪ Is the origin of the requirement clearly stated? 

     ▪ Adaptability 

         ▪ Can the requirement be changed without a large impact on other requirements?