Lectures Software Engineering - Chapter 6: Requirements Engineering Processes

61 trang hoanguyen 2610

Download

Bạn đang xem 20 trang mẫu của tài liệu "Lectures Software Engineering - Chapter 6: Requirements Engineering Processes", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

lectures_software_engineering_chapter_6.ppt

Nội dung text: Lectures Software Engineering - Chapter 6: Requirements Engineering Processes

Requirements Engineering Processes l Processes used to discover, analyse and validate system requirements ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1
Objectives l To describe the principal requirements engineering activities l To introduce techniques for requirements elicitation and analysis l To describe requirements validation l To discuss the role of requirements management in support of other requirements engineering processes ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 2
Topics covered l Feasibility studies l Requirements elicitation and analysis l Requirements validation l Requirements management ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 3
Requirements engineering processes l The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements l However, there are a number of generic activities common to all processes • Requirements elicitation • Requirements analysis • Requirements validation • Requirements management ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 4
Feasibility studies l A feasibility study decides whether or not the proposed system is worthwhile l A short focused study that checks • If the system contributes to organisational objectives • If the system can be engineered using current technology and within budget • If the system can be integrated with other systems that are used ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 6
Feasibility study implementation l Based on information assessment (what is required), information collection and report writing l Questions for people in the organisation • What if the system wasn’t implemented? • What are current process problems? • How will the proposed system help? • What will be the integration problems? • Is new technology needed? What skills? • What facilities must be supported by the proposed system? ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 7
Elicitation and analysis l Sometimes called requirements elicitation or requirements discovery l 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 l May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 8
Problems of requirements analysis l Stakeholders don’t know what they really want l Stakeholders express requirements in their own terms l Different stakeholders may have conflicting requirements l Organisational and political factors may influence the system requirements l The requirements change during the analysis process. New stakeholders may emerge and the business environment change ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 9
Process activities l Domain understanding l Requirements collection l Classification l Conflict resolution l Prioritisation l Requirements checking ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 11
System models l Different models may be produced during the requirements analysis activity l Requirements analysis may involve three structuring activities which result in these different models • Partitioning. Identifies the structural (part-of) relationships between entities • Abstraction. Identifies generalities among entities • Projection. Identifies different ways of looking at a problem l System models covered in Chapter 7 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 12
Viewpoint-oriented elicitation l Stakeholders represent different ways of looking at a problem or problem viewpoints l This multi-perspective analysis is important as there is no single correct way to analyse system requirements ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 13
Banking ATM system l The example used here is an auto-teller system which provides some automated banking services l I use a very simplified system which offers some services to customers of the bank who own the system and a narrower range of services to other customers l Services include cash withdrawal, message passing (send a message to request a service), ordering a statement and transferring funds ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 14
Autoteller viewpoints l Bank customers l Representatives of other banks l Hardware and software maintenance engineers l Marketing department l Bank managers and counter staff l Database administrators and security staff l Communications engineers l Personnel department ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 15
Types of viewpoint l Data sources or sinks • Viewpoints are responsible for producing or consuming data. Analysis involves checking that data is produced and consumed and that assumptions about the source and sink of data are valid l Representation frameworks • Viewpoints represent particular types of system model. These may be compared to discover requirements that would be missed using a single representation. Particularly suitable for real-time systems l Receivers of services • Viewpoints are external to the system and receive services from it. Most suited to interactive systems ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 16
External viewpoints l Natural to think of end-users as receivers of system services l Viewpoints are a natural way to structure requirements elicitation l It is relatively easy to decide if a viewpoint is valid l Viewpoints and services may be sued to structure non-functional requirements ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 17
Method-based analysis l Widely used approach to requirements analysis. Depends on the application of a structured method to understand the system l Methods have different emphases. Some are designed for requirements elicitation, others are close to design methods l A viewpoint-oriented method (VORD) is used as an example here. It also illustrates the use of viewpoints ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 18
VORD process model l Viewpoint identification • Discover viewpoints which receive system services and identify the services provided to each viewpoint l Viewpoint structuring • Group related viewpoints into a hierarchy. Common services are provided at higher-levels in the hierarchy l Viewpoint documentation • Refine the description of the identified viewpoints and services l Viewpoint-system mapping • Transform the analysis to an object-oriented design ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 20
Scenarios l Scenarios are descriptions of how a system is used in practice l They are helpful in requirements elicitation as people can relate to these more readily than abstract statement of what they require from a system l Scenarios are particularly useful for adding detail to an outline requirements description ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 27
Scenario descriptions l System state at the beginning of the scenario l Normal flow of events in the scenario l What can go wrong and how this is handled l Other concurrent activities l System state on completion of the scenario ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 28
Event scenarios l Event scenarios may be used to describe how a system responds to the occurrence of some particular event such as ‘start transaction’ l VORD includes a diagrammatic convention for event scenarios. • Data provided and delivered • Control information • Exception processing • The next expected event ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 29
Notation for data and control analysis l Ellipses. data provided from or delivered to a viewpoint l Control information enters and leaves at the top of each box l Data leaves from the right of each box l Exceptions are shown at the bottom of each box l Name of next event is in box with thick edges ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 31
Exception description l Most methods do not include facilities for describing exceptions l In this example, exceptions are • Timeout. Customer fails to enter a PIN within the allowed time limit • Invalid card. The card is not recognised and is returned • Stolen card. The card has been registered as stolen and is retained by the machine ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 32
Use cases l Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself l A set of use cases should describe all possible interactions with the system l Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 33
Social and organisational factors l Software systems are used in a social and organisational context. This can influence or even dominate the system requirements l Social and organisational factors are not a single viewpoint but are influences on all viewpoints l Good analysts must be sensitive to these factors but currently no systematic way to tackle their analysis ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 37
Example l Consider a system which allows senior management to access information without going through middle managers • Managerial status. Senior managers may feel that they are too important to use a keyboard. This may limit the type of system interface used • Managerial responsibilities. Managers may have no uninterrupted time where they can learn to use the system • Organisational resistance. Middle managers who will be made redundant may deliberately provide misleading or incomplete information so that the system will fail ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 38
Ethnography l A social scientists spends a considerable time observing and analysing how people actually work l People do not have to explain or articulate their work l Social and organisational factors of importance may be observed l Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 39
Focused ethnography l Developed in a project studying the air traffic control process l Combines ethnography with prototyping l Prototype development results in unanswered questions which focus the ethnographic analysis l Problem with ethnography is that it studies existing practices which may have some historical basis which is no longer relevant ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 40
Scope of ethnography l Requirements that are derived from the way that people actually work rather than the way I which process definitions suggest that they ought to work l Requirements that are derived from cooperation and awareness of other people’s activities ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 42
Requirements validation l Concerned with demonstrating that the requirements define the system that the customer really wants l 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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 43
Requirements checking l Validity. Does the system provide the functions which best support the customer’s needs? l Consistency. Are there any requirements conflicts? l Completeness. Are all functions required by the customer included? l Realism. Can the requirements be implemented given available budget and technology l Verifiability. Can the requirements be checked? ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 44
Requirements validation techniques l Requirements reviews • Systematic manual analysis of the requirements l Prototyping • Using an executable model of the system to check requirements. Covered in Chapter 8 l Test-case generation • Developing tests for requirements to check testability l Automated consistency analysis • Checking the consistency of a structured requirements description ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 45
Requirements reviews l Regular reviews should be held while the requirements definition is being formulated l Both client and contractor staff should be involved in reviews l Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 46
Review checks l Verifiability. Is the requirement realistically testable? l Comprehensibility. Is the requirement properly understood? l Traceability. Is the origin of the requirement clearly stated? l Adaptability. Can the requirement be changed without a large impact on other requirements? ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 47
Requirements management l Requirements management is the process of managing changing requirements during the requirements engineering process and system development l Requirements are inevitably incomplete and inconsistent • New requirements emerge during the process as business needs change and a better understanding of the system is developed • Different viewpoints have different requirements and these are often contradictory ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 49
Requirements change l The priority of requirements from different viewpoints changes during the development process l System customers may specify requirements from a business perspective that conflict with end-user requirements l The business and technical environment of the system changes during its development ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 50
Enduring and volatile requirements l Enduring requirements. Stable requirements derived from the core activity of the customer organisation. E.g. a hospital will always have doctors, nurses, etc. May be derived from domain models l Volatile requirements. Requirements which change during development or when the system is in use. In a hospital, requirements derived from health-care policy ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 52
Classification of requirements l Mutable requirements • Requirements that change due to the system’s environment l Emergent requirements • Requirements that emerge as understanding of the system develops l Consequential requirements • Requirements that result from the introduction of the computer system l Compatibility requirements • Requirements that depend on other systems or organisational processes ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 53
Requirements management planning l During the requirements engineering process, you have to plan: • Requirements identification » How requirements are individually identified • A change management process » The process followed when analysing a requirements change • Traceability policies » The amount of information about requirements relationships that is maintained • CASE tool support » The tool support required to help manage requirements change ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 54
Traceability l Traceability is concerned with the relationships between requirements, their sources and the system design l Source traceability • Links from requirements to stakeholders who proposed these requirements l Requirements traceability • Links between dependent requirements l Design traceability • Links from the requirements to the design ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 55
CASE tool support l Requirements storage • Requirements should be managed in a secure, managed data store l Change management • The process of change management is a workflow process whose stages can be defined and information flow between these stages partially automated l Traceability management • Automated retrieval of the links between requirements ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 57
Requirements change management l Should apply to all proposed changes to the requirements l Principal stages • Problem analysis. Discuss requirements problem and propose change • Change analysis and costing. Assess effects of change on other requirements • Change implementation. Modify requirements document and other documents to reflect change ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 58
Key points l The requirements engineering process includes a feasibility study, requirements elicitation and analysis, requirements specification and requirements management l Requirements analysis is iterative involving domain understanding, requirements collection, classification, structuring, prioritisation and validation l Systems have multiple stakeholders with different requirements ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 60
Key points l Social and organisation factors influence system requirements l Requirements validation is concerned with checks for validity, consistency, completeness, realism and verifiability l Business changes inevitably lead to changing requirements l Requirements management includes planning and change management ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 61