Download presentation
Presentation is loading. Please wait.
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 System development domain Problem domain
Requirements Engineers System development domain Problem domain 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 System developers require •The requirements must be feasible, necessary and sufficient
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 Requirements are
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
17
NFR product usability Reliability Portability Efficiency Performance space External Interoperability Legislative Privacy Safety Ethical Organizational Delivery Standard Implementation
18
NFR-types Product requirements • Organizational 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
19
NFR measures – turn vague idea about quality into measurable
Speed Process transaction/second User/Event response time Screen refresh time Size M Bytes Number of ROM chips Ease of use Training time Number of help frames Reliability Mean time to failure Percentage of events causing failure Robustness Probability of data corruption on failure Availability Time to restart after failure Rate of failure occurrence Probability of unavailability Portability Percentage of target dependent statements Number of target systems
20
The outline Requirements engineering and requirements management
What is requirements Classification of requirements RE process Stakeholders in RE
21
RE process – inputs and outputs
Existing system information Agreed requirements RE process Stakeholder needs System specification Organisational standards System models Regulations Domain information
22
Input/output description
23
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 EP (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”
24
Spiral model of the RE process
25
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
26
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
27
Risks from inadequate requirements processes
Insufficient user involvement -> unacceptable products 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
28
Key benefits of good requirements processes
Better control of complex projects Improved system quality and customer satisfaction Reduced project cost and delay Improved team communication
29
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
30
A requirements management system
31
Requirements management tools
Requirements browser Requirements query system Traceability support system Report generator Requirements converter and word processor linker Change control system
32
Requirements management tools
List of requirements tools INCOSE requirements management tool survey: A requirements tool for agile web application Development
33
The outline Requirements engineering and requirements management
What is requirements Classification of requirements RE process Stakeholders in RE
34
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)
35
Type of stakeholders
36
Role descriptions
37
Stakeholder analysis
38
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
39
Stakeholder analysis process
40
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)
41
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?
42
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, …
43
Stakeholder profile - HAS
Major value Attitudes Major interests constraints Resident Authorization control of the home appliances, reduce cost Concern about ease-of-use; most residents excited Comfort, security and life safety Control should be largely image-based and self-explanatory
44
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)
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.