Requirements Engineering Requirements Management Lecture-26.

Slides:



Advertisements
Similar presentations
Requirements Engineering Process
Advertisements

Requirements Engineering Process
Configuration management
Configuration management
Requirements Specification
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
Requirements Management
Requirements Engineering Processes
IS550: Software requirements engineering Dr. Azeddine Chikh 4. Validation and management.
1 SWE Introduction to Software Engineering Lecture 11 - Requirements Engineering Processes.
Course Instructor: Aisha Azeem
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Rapid software development.
Software maintenance Managing the processes of system change.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes 1.
Chapter 9 – Software Evolution and Maintenance
This chapter is extracted from Sommerville’s slides. Text book chapter
CS 4310: Software Engineering
Dr Suad AlRamouni. ◦ Understand some key terms used in software requirements engineering. ◦ Distinguish requirements development from requirements management.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyze and.
Chapter 3: Software Maintenance Process Omar Meqdadi SE 3860 Lecture 3 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Quality Model for Requirements Eng. Copyright, 2002 © Jerzy R. Nawrocki Quality.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 1 Configuration management l Managing the products of system change.
 To explain the importance of software configuration management (CM)  To describe key CM activities namely CM planning, change management, version management.
Requirements Engineering CSE-305 Requirements Engineering Process Tasks Lecture-5.
Requirements Elicitation. Who are the stakeholders in determining system requirements, and how does their viewpoint influence the process? How are non-technical.
 To describe the principal requirements engineering activities and their relationships  To introduce techniques for requirements elicitation and analysis.
Software Requirements Engineering CSE 305 Lecture-2.
Configuration Management (CM)
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 1 Configuration management.
Creator: ACSession No: 16 Slide No: 1Reviewer: SS CSE300Advanced Software EngineeringFebruary 2006 (Software Quality) Configuration Management CSE300 Advanced.
Chapter 4 Requirements Engineering Processes Objectives l To describe the principal requirements engineering activities and their relationships l To.
Good Practices of Requirements Eng. Copyright, 2000 © Jerzy R. Nawrocki Requirements.
Requirements Management. Learning outcome Explain why requirements management is important Explain reasons of requirements change.
Lecture 7: Requirements Engineering
Configuration Management and Change Control Change is inevitable! So it has to be planned for and managed.
SOFTWARE REQUIREMENT ANALYSIS AND SPECIFICATION. What is a requirement? It may range from a high-level abstract statement of a service or of a system.
W EEK 13 Requirements traceability and interdependencies.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
 Dr. Syed Noman Hasany.  Review of known methodologies  Analysis of software requirements  Real-time software  Software cost, quality, testing and.
Quality Model for RE Process Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
Requirements Engineering Process
1 Chapter 12 Configuration management This chapter is extracted from Sommerville’s slides. Text book chapter 29 1.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
Requirements Engineering Requirements Validation and Management Lecture-24.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Requirements Engineering Requirements Management Lecture-25.
Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates.
CS223: Software Engineering Lecture 8: Requirement Engineering.
Design and implementation Chapter 7 – Lecture 1. Design and implementation Software design and implementation is the stage in the software engineering.
Software Engineering Lecture 10: System Engineering.
Requirements Engineering Processes, York EngD Programme, 2009Slide 1 Requirements engineering processes Prof Ian Sommerville.
 The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.  However,
 System Requirement Specification and System Planning.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
1 Requirements Management - II Lecture # Recap of Last Lecture We talked about requirements management and why is it necessary to manage requirements.
Requirements Engineering Processes
Requirements Engineering Process
Chapter 5 – System Modeling
Requirements Traceability
Requirements Traceability
Chapter 9 – Software Evolution and Maintenance
Chapter 8 Software Evolution.
Requirements Management - I
Requirements Traceability
Requirements Document
Configuration management
Rapid software development
Presentation transcript:

Requirements Engineering Requirements Management Lecture-26

Recap 2  Requirements management  Change management process  Change analysis

Change management stages

Change analysis and costing

Today’s lecture 5  Requirements management  Traceability

Traceability  Traceability information is information which helps you assess the impact of requirements change. It links related requirements and the requirements and other system representations  Types of traceability information  Backward-from traceability Links requirements to their sources in other documents or people  Forward-from traceability Links requirements to the design and implementation components  Backward-to traceability Links design and implementation components backs to requirements  Forward-to traceability Links other documents (which may have preceded the requirements document) to relevant requirements.

Backwards/forwards traceability

Types of traceability  Requirements-sources traceability  Links the requirement and the people or documents which specified the requirement  Requirements-rationale traceability  Links the requirement with a description of why that requirement has been specified.  Requirements-requirements traceability  Links requirements with other requirements which are, in some way, dependent on them. This should be a two-way link (dependants and is-dependent on).

Types of traceability  Requirements-architecture traceability  Links requirements with the sub-systems where these requirements are implemented. This is particularly important where sub-systems are being developed by different sub- contractors  Requirements-design traceability  Links requirements with specific hardware or software components in the system which are used to implement the requirement  Requirements-interface traceability  Links requirements with the interfaces of external systems which are used in the provision of the requirements

Traceability tables  Traceability tables show the relationships between requirements or between requirements and design components  Requirements are listed along the horizontal and vertical axes and relationships between requirements are marked in the table cells  Traceability tables for showing requirements dependencies should be defined with requirement numbers used to label the rows and columns of the table

A traceability table

Traceability lists  If a relatively small number of requirements have to be managed (up to 250, say), traceability tables can be implemented using a spreadsheet  Traceability tables become more of a problem when there are hundreds or thousands of requirements as the tables become large and sparsely populated  A simplified form of traceability table may be used where, along with each requirement description, one or more lists of the identifiers of related requirements are maintained.  Traceability lists are simple lists of relationships which can be implemented as text or as simple tables

A traceability list

Traceability policies  Traceability policies define what and how traceability information should be maintained.  Traceability policies may include  The traceability information which should be maintained.  Techniques, such as traceability matrices, which should be used for maintaining traceability.  A description of when the traceability information should be collected during the requirements engineering and system development processes.  The roles of the people, such as the traceability manager, who are responsible for maintaining the traceability information should also be defined.  A description of how to handle and document policy exceptions  The process of managing traceability information

Factors influencing traceability policies  Number of requirements  The greater the number of requirements, the more the need for formal traceability policies.  Estimated system lifetime  More comprehensive traceability policies should be defined for systems which have a long lifetime.  Level of organisational maturity  Detailed traceability policies are most likely to be cost-effective in organisations which have a higher level of process maturity

Factors influencing traceability policies  Project team size and composition  With a small team, it may be possible to assess the impact of proposed informally without structured traceability information. With larger teams, however, you need more formal traceability policies.  Type of system  Critical systems such as hard real-time control systems or safety-critical systems need more comprehensive traceability policies than non-critical systems.  Specific customer requirements  Some customers may specify that specific traceability information should be delivered as part of the system documentation.

Key points  Requirements change is inevitable as customers develop a better understanding of their real needs and as the political, organisational and technical environment in which a system is to be installed changes.  Requirements which are concerned with the essence of a system are more likely to be stable than requirements which are more concerned with how the system is implemented in a particular environment.  Types of volatile requirement include mutable requirements, emergent requirements, consequential requirements and compatibility requirements.  Requirements management requires that each requirement should be uniquely identified.  If a large number of requirements have to be managed, the requirements should be stored in a database and links between related requirements should be maintained.

Key points  Change management policies should define the processes used for change management and the information which should be associated with each change request. They should also define who is responsible for doing what in the change management process.  Some automated support for change management should be provided. This may come through specialised requirements management tools or by configuring existing tools to support change management  Traceability information records the dependencies between requirements and the sources of these requirements, dependencies between requirements and dependencies between the requirements and the system implementation.  Traceability matrices may be used to record traceability information.  Collecting and maintaining traceability information is expensive. To help control these costs, organisations should define a set of traceability policies which set out what information is to be collected and how it is to be maintained.

Summary Software Engineering-II19  Requirements traceability  Types of traceability information  Types of traceability  Traceability lists and tables  Traceability policies