Slide 1

Requirements Engineering Processes

Atique Zafar

COMSATS Institute of Information Technology

Requirements Engineering

ProcessesA process is an organised set of activities which transforms inputs to outputsProcess descriptions encapsulate knowledge and allow it to be reusedExamples of process descriptionsInstruction manual for a dishwasherCookery bookProcedures manual for a bankQuality manual for software development

Design processesProcesses which involve creativity, interactions between a wide range of different people, engineering judgement and background knowledge and experienceExamples of design processesWriting a bookOrganising a conferenceDesigning a processor chipRequirements engineering

RE process - inputs and outputs

Input/output description

Explanation with examplesSoftware Engineering-II61. Existing system informationAssume that the system has to interface with a bar code reader system which has already been installed and which generates a queue of bar codes for processing and associated transaction requests. Example: The LIS shall poll the bar code reader system and process all of the transaction requests every two seconds.2. Stakeholder needsAssume that the stakeholder is a visitor to the library who has no previous experience of using the system. Example: The system should provide a help facility which will explain the facilities of the system to new users. This help facility should be accessible from all user interface screens.3. Organizational standardsAssume that the library uses a hardware platform for all of its systems.Example: The system shall run on a Sun server running the Solaris 2.0 operating system.4. RegulationsRegulations such as health and safety regulations are unlikely to have much impact on this type of system. However, data protection laws do apply to it. Example: The system shall include a facility to print all of the personal information which is maintained for a library user.5. Domain informationThis is general information which is applicable to all or most library systems. Example: Books are uniquely identified by an International Standard Book Number which is a 10 digit identifier .

RE process variabilityRE processes vary radically from one organisation to anotherFactors contributing to this variability includeTechnical maturityDisciplinary involvementOrganisational cultureApplication domainThere is therefore no ideal requirements engineering process

Requirements EngineeringProcessesLike a life cycle development process there are some limited numbers of requirements engineering processes available. These are the set of activities involved in development ofrequirements.

Linear Requirements Engineering ProcessModelSoftware Engineering-II9Mostly used for small projects with some less amount of complexity ProblemsNot good for some large and huge projects to get their requirements because,No user feedback, no validation of requirements,No iterations of RE, The most important that there is no strategy defined for risk management.

Linear Iterative RequirementsEngineering Process Model

ContSoftware Engineering-II11This model is useful for the system where the specifications should be pin point accurate and should be validated multiple numbers of times through the potential stakeholders.Solves some of the problems of linear RE process modelsuch as freezing of requirements and requirements invalidation. ProblemsNo reverse engineering is possible and No risk management is suggested by this model.

Iterative RE Process ModelSoftware Engineering-II12Used to perform the requirements engineering in multiple iterations Better for those software development which are launched versions by versions in the market.

ContSoftware Engineering-II13Suggests the user and domain information feedback in case of new iteration in the product. ProblemStill there is no methodology set to manage the risks in the project.

Spiral Model of RE ProcessSoftware Engineering-II14One spiral represents the complete version of the requirements on the bases of which the system has to be developed. Each spiral is divided into four quadrants called specification elicitation, requirements analysis and negotiation, requirements documentations and requirements validations. The main characteristic of this model is to handle the unwanted consequences called risks such as speciation delay, requirements change.

Spiral model of the RE process

Actors in the RE processActors in a process are the people involved in the execution of that processActors are normally identified by their roles rather than individuallyRequirements engineering involves actors who are primarily interested in the problem to be solved (end-users, etc) as well actors interested in the solution (system designers, etc.)Role-action diagrams document which actors are involved in different activities

RAD for software prototyping

Role descriptions

Human and social factorsRequirements engineering processes are dominated by human, social and organisational factors because they always involve a range of stakeholders from different backgrounds and with different individual and organisational goals.System stakeholders may come from a range of technical and non-technical background and from different disciplines

Types of stakeholderSoftware engineers responsible for system developmentSystem end-users who will use the system after it has been deliveredManagers of system end-users who are responsible for their workExternal regulators who check that the system meets its legal requirementsDomain experts who give essential background information about the system application domain

Factors influencing requirementsPersonality and status of stakeholdersThe personal goals of individuals within an organisationThe degree of political influence of stakeholders within an organisation

Input or outputTypeDescriptionExisting system informationInputInformation about the functionality of systems to be replaced or other systems which interact with the system being specifiedStakeholder needsInputDescriptions of what system stakeholders need from the system to support their workOrganisational standardsInputStandards used in an organisation regarding system development practice, quality management, etc.RegulationsInputExternal regulations such as health and safety regulations which apply to the system.Domain informationInputGeneral information about the application domain of the systemAgreed requirementsOutputA description of the system requirements which is understandable by stakeholders and which has been agreed by themSystem specificationOutputThis is a more detailed specification of the system functionality which may be produced in some casesSystem modelsOutputA set of models such as a data-flow model. an object model, a process model, etc. which describes the system from different perspectives

RoleDescriptionDomain expertResponsible for providing information about the application domain and the specific problem in that domain which is to be solved.System end-userResponsible for using the system after deliveryRequirements engineerResponsible for eliciting and specifying the system requirementsSoftware engineerResponsible for developing the prototype software systemProject managerResponsible for planning and estimating the prototyping project