1 / 44

Requirements Engineering Process

Requirements Engineering Process. Week 3. The outline. Requirements engineering and requirements management What is requirements Classification of requirements RE process Stakeholders in RE. The context of RE. Problem domain . System developers require

ricky
Télécharger la présentation

Requirements Engineering Process

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements Engineering Process Week 3

  2. The outline • Requirements engineering and requirements management • What is requirements • Classification of requirements • RE process • Stakeholders in RE

  3. The context of RE Problem domain System developers require •The requirements must be feasible, necessary and sufficient System development domain Requirements Engineers • System users and other stakeholders may • not be able to accurately describe what they do • not know what is technically feasible, • change their minds once they see the possibilities more clearly, and • often not appreciate the complexity inherent in software engineering, and the impact of changed requirements

  4. Overview • This course looks at software requirements from both engineering and management perspectives. • It is an engineering activity because • identifying appropriate methodologies to develop software solutions and • identifying cost effective ways of doing so. • In other words, the aim of RE is to introduce engineering principles into the practice of software systems analysis while integrating RE with a quality assurance process of utmost value to practitioners.

  5. Overview • RE is the systematic process of developing requirements through an iterative co-operative process of analyzing the problem, documenting the resulting observations in a variety of representation formats and checking the accuracy of the understanding gained (Pohl, 1993) • A social process • A variety of representation formats • Understanding and validating the requirements • Typical RE products • System requirements specification, and associated analysis models of requirements baseline • A vision and scope document • A requirements specification

  6. Overview • Requirements change during the software development lifecycle and evolve after the system has become operational. • Thus, RE is also a “management” activity as it is concerned with managing RE activities such as • monitoring product requirements and • managing the project scope, cost and schedule throughout the software development process, while ensuring that all essential business applications are delivered as specified in different requirements documents on different levels, for example, product and project levels.

  7. Overview • RM involves processes, tools and practice to maintain the integrity and accuracy of the requirements agreement • Change control –managing changes to agreed requirements • Version control –identifying document versions and requirements revisions • Requirements tracing –managing relationships between requirements, and dependencies among requirement document • Requirements status tracking –defining and tracking status

  8. Marketing, Customers, Management Requirements Analyze, Document, Review, Negotiate Baselined Requirements current baseline revised baseline Marketing, customers, management requirements change Process Project Environment Requirements changes Project changes

  9. The outline • Requirements engineering and requirements management • What is requirements • Classification of requirements • RE process • Stakeholders in RE

  10. What is requirements • A requirement is • a singular documented need of what a particular product or service should be or do. - Wikipedia • Requirements are • specifications of the services that the system should provide, the constraints on the system and the background information that is necessary to developing the system (Zave 1997) • Requirements are … • a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. • They may be • a constraint on the development process of the system (Sommerville and Sawyer 1997)

  11. Example Home security requirements for a Home Automation System (HAS) R2: The alarm signal shall start immediately after the detection of the open Window or door. (refer to R78) – R2.1: The alarm signal shall be deactivated by the police, by the owner, or Automatically after 20 min. – … … – R78: The time period between motion detection and start of alarm signal shall be less than 0.5 seconds

  12. Levels of requirements • Business requirements • High-level objectives of organization or customer requesting the system • Vision and scope document • User requirements • Statements of the services and the operational constraints • E.g. use case or scenario descriptions • System requirements • Detailed descriptions of the system services • E.g. development, testing, quality assurance, project management (schedule, budget, etc.) • Software specification - A detailed software description which can serve as a basis for a design or implementation

  13. Examples: home security requirements in HAS Business Requirements: The HAS shall ensure home security. • User Requirements: The HAS shall protect again burglary. • System Requirements • F1: Video surveillance; F2: Alarm activation; … … ; • Fn: Alarm call • Software Specification • R2: The alarm signal shall start immediately after the detection of the open window or door. • R2.1: The alarm signal shall be deactivated by the police, by the owner, or automatically after 20 min. • R79: The time period between motion detection and start of recording shall be less than 0.5 seconds.

  14. The outline • Requirements engineering and requirements management • What is requirements • Classification of requirements • RE process • Stakeholders in RE

  15. Requirements classification • Requirements may be functional or non-functional • Functional requirements (FRs) describe the functionality of the system, can be modeled with use cases • Non-functional requirements (NFRs) describe system properties related to e.g. system performance, usability, security, maintainability… • Constraints impose limitations on the design of the system , or process by which it is developed, that do not affect the external behavior • E.g. CASE system, programming language or development method

  16. NFR-types • Product requirements • Requirements which specify that the delivered product must behave in a particular way • E.g. R78: The time period between motion detection and start of alarm signal shall be less than 0.5 seconds. • • Organizational requirements • Requirements which are a consequence of organizational policies and procedures • E.g. The signal powerline transmission shall use the standard X10. • • External requirements • Requirements which arise from factors which are external to the system and its development process • E.g. The alarm signal shall be deactivated by the police, by the owner, or automatically after 20 min

  17. NFR measures – turn vague idea about quality into measurable

  18. The outline • Requirements engineering and requirements management • What is requirements • Classification of requirements • RE process • Stakeholders in RE

  19. RE process – inputs and outputs Existing system information Agreed requirements RE process Stakeholder needs System specification Organisational standards System models Regulations Domain information

  20. Input/output description

  21. Examples - HAS • Existing system information – “The power outlets shall be shut down on the detection of fire.” • Stakeholder needs – “The resident shall be informed immediately after the detection of an open window or door” • Organizational standards – “The signal powerline transmission shall use the standard X10” • Regulations – “The method for temperature control in individual living or work rooms shall be EP0631219 (December, 1994).” • Domain information – “The password shall consist of at least 10 characters and include special characters (such as numbers). The password shall be changes every 3 months, and an old password can not be used again”

  22. Spiral model of the RE process

  23. RE process activities • Requirements elicitation • Requirements discovered through consultation with stakeholders, from system documents, domain knowledge and market studies • Requirements analysis and negotiation • Requirements are analyzed and conflicts resolved through negotiation • Requirements documentation - A requirements document is produced • Requirements validation • The requirements document is checked for consistency and completeness

  24. RE variability • RE processes vary radically from one organization to another • Factors contributing to this variability include • Technical maturity • Disciplinary involvement • Organizational culture • Application domain • There is no ‘ideal’ requirements engineering process

  25. Risks from inadequate requirementsprocesses • Insufficient user involvement -> unacceptableproducts • Creeping user requirements -> overruns/degrade product quality • Ambiguous requirements -> ill-spent time and rework • Overlooked user classes -> dissatisfied customers • Minimal specifications -> missing key requirements • Incompletely defined requirements -> impossible to accurate project planning and later tracking • Missing requirements are hard to spot because they are not there! ( Wiegers, 2003) • Gold-plating -> unnecessary features

  26. Key benefits of good requirementsprocesses • Better control of complex projects • Improved system quality and customer satisfaction • Reduced project cost and delay • Improved team communication

  27. Tools support for RE process • Support for requirements engineering is limited because of the informality and the variability of the process • Modeling tools support the development of system models which can be used to specify the system and the checking of these models for completeness and consistency • Management tools help manage a database of requirements and support the management of changes to these requirements

  28. A requirements management system

  29. Requirements management tools • Requirements browser • Requirements query system • Traceability support system • Report generator • Requirements converter and word processor linker • Change control system

  30. Requirements management tools • List of requirements tools • INCOSE requirements management tool survey: • http://www.paper-review.com/tools/rms/read.php • http://easyweb.easynet.co.uk/~iany/other/vendors.htm • http://www.volere.co.uk/tools.htm • A requirements tool for agile web application Development • http://demo.agiletool.org/

  31. The outline • Requirements engineering and requirements management • What is requirements • Classification of requirements • RE process • Stakeholders in RE

  32. Stakeholders in the RE process • Stakeholders include the parties that can influence or be affected by a certain problem • Stakeholders - Roles • RE involves stakeholders • Interested in the problem to be solved (end-users) • Interested in the solution (system designer)

  33. Type of stakeholders

  34. Role descriptions

  35. Stakeholder analysis

  36. Stakeholder analysis • Stakeholder analysis is an approach for understanding a system by identifying the stakeholders in the system, • and assessing their respective interests in, or influence on the system • Stakeholder identification • Stakeholder profiling • Stakeholder prioritization

  37. Stakeholder analysis process

  38. Stakeholder identification • Baseline stakeholders -> the network of stakeholders(Sharp et al. 1999) • Baseline stakeholders: Users, Developers, Legislators, Decision makers, Physical environments • A combination of following methods is useful for exploring the network of stakeholders • Checklist • Self-selection (Documentation studies) • Experts • Identified stakeholders (brainstorming, interview) http://eprints.ucl.ac.uk/744/1/1.7_stake.pdf

  39. Example of checklist questions • Who are the user groups of the system? • Who is the customer (economic buyer) for the system? • Who else will be affected by the outputs the system produces? • Who will evaluate and approve the system when it is delivered and deployed? • Are there any other internal or external users? • Who will maintain the new system? • Is there anyone else who cares? • What other systems interact with this system?

  40. Stakeholder profiling • The stakeholders profile records their own concerns of the system, including their interests, characteristics, etc. • Definition, job description, relationship to the development team • Goals, needs and desires, concerns, declared interests, responsibilities, tasks to be performed • The relationship between stakeholders, stakeholder power and importance • Methods useful for profile creation • Conversational methods –interview, workshop, … • Analytic methods, document studies, …

  41. Stakeholder profile - HAS

  42. Stakeholder relationship identification and prioritization • Understand the relationships between stakeholders • Identify conflicts of interests between stakeholders • Identify relations between stakeholders that may enable ”coalitions”of project sponsorship, ownership and cooperation • Assess the importance and influence of each stakeholder on the project • How stakeholders problems, needs, and interest coincides with the aims of the project • (How powerful the stakeholder is) • (Stakeholder prioritization –Importance/Influence grid)

More Related