Requirements Engineering (CS 5032 2012)

1,567
-1

Published on

An introduction to requirements engineering for students with no previous background in this area. Part of critical systems engineering course, CS 5032.

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,567
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
68
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Requirements Engineering (CS 5032 2012)

  1. 1. Requirements Engineering Professor Ian SommervilleL3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 1
  2. 2. Requirements and systems User Software-based world system RequirementsL3 - Requirements Engineering, Critical Systems Engineering, 2011 Photo © Liam Quinn Slide 2
  3. 3. What are system requirements? • Requirements are defined during the early stages of a system development as a specification of what should be implemented or as a constraint of some kind on the system. • They may be: – a user-level facility description, – a detailed specification of expected system behaviour, – a general system property, – a specific constraint on the system, – information on how to carry out some computation, – a constraint on the development of the system.L3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 3
  4. 4. Examples of requirements • Functional requirements “If a patient is known to be allergic to a particular medication, then prescription of that medication shall result in a warning message being issued to to the prescriber” • Non-functional requirements “The system shall be available to all clinics during normal working hours (Mon-Fri, 0830-1730). Downtime during normal working hours shall not exceed 5 seconds in any one day” • Domain requirements “The system shall implement patient privacy provisions as set out in the 1998 Data Protection Act”L3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 4
  5. 5. What is requirements engineering? • Requirements engineering covers all of the activities involved in discovering, documenting, and maintaining a set of requirements for a computer-based system. • The use of the term „engineering‟ implies that systematic and repeatable techniques should be used to ensure that system requirements are complete, consistent, relevant, etc.L3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 5
  6. 6. Are requirements important? • European Software Process Improvement Training Initiative (1996) “The principal problem areas in software development and production are the requirements specification and the management of customer requirements” • In a study of errors in embedded systems, it was found that: “... difficulties with requirements are the key root- cause of the safety-related software errors that have persisted until integration and system testing”L3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 6
  7. 7. What happens if the requirements are wrong? • The system may be delivered late and cost more than originally expected. • The customer and end-users are not satisfied with the system. They may not use its facilities or may even decide to scrap it altogether. • The system may be unreliable in use with regular system errors and crashes disrupting normal operation. • If the system continues in use, the costs of maintaining and evolving the system are very high.L3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 7
  8. 8. Why is RE difficult? • Changing environments – Businesses operate in a rapidly changing environment so their requirements for system support are constantly changing. • Differing views – Multiple stakeholders with different goals and priorities are involved in the requirements engineering process. • Unclear opinions – System stakeholders do not have clear ideas about the system support that they need. • Politics and people – Requirements are often influenced by political andL3 - Requirements Engineering, Critical Systems Engineering, 2011 stakeholders will not admit to Slide 8 organisational factors that
  9. 9. Requirements engineering terminology Terms that you should understand Stakeholders, viewpoints and concernsL3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 9
  10. 10. Stakeholders • People or roles who are affected, in some way, by a system and so who can contribute requirements or knowledge to help you understand the requirements • Example – medical system stakeholders – Doctors – Nurses – Patients – Hospital managers – Administrators – Owners of other connected systemsL3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 10
  11. 11. Viewpoints • Viewpoints are a way of organising and grouping requirements that have been elicited from stakeholders • The requirements generally represent the views and needs of a class or type of stakeholder • Examples of viewpoints – End-user viewpoint – Managerial viewpoint – System administration viewpoint – Engineering viewpointL3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 11
  12. 12. Stakeholders and viewpoints Stakeholde rs Provide information about VP2 VP1 VP4 VP3 RequirementsL3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 12
  13. 13. Concerns • Are issues that an organisation must pay attention to and that are systemic i.e. they apply to the system as a whole • They are cross-cutting issues that may affect all system stakeholders and the requirements from these stakeholders • Concerns help bridge the gap between organisational goals (what the organisation has to achieve) and system requirements (how a system contributes to these goals)L3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 13
  14. 14. Concerns Software and hardware Operators and managers The organisation Society Security Availability SafetyL3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 14
  15. 15. Requirements engineering processes Different views of the processes involved in requirements engineeringL3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 15
  16. 16. The systems engineering process System System requirements validation engineering Architectural System design integration Requirements Sub-system partitioning development Software requirements engineeringL3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 16
  17. 17. RE process context System acquisition Requirements engineering System designL3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 17
  18. 18. RE process inputs and outputs Existing systems information Stakeholder Agreed needs requirements Requirements System Organisational engineering process standards specification System Regulations models Domain informationL3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 18
  19. 19. RE process activities Requirements Requirements Requirements analysis and Requirements elicitation documentation validation negotiation User needs domain Requirements information, document Agreedexisting system System requirements information, specification regulations,standards, etc. L3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 19
  20. 20. RE process iteration Informal statement of Decision point: requirements Accept document or re-enter spiral Requirements elicitation Requirements analysis and negotiation Requirements START document and Agreed validation requirements report Requirements validation Requirements documentation Draft requirements documentL3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 20
  21. 21. Requirements engineering problems Fundamental issues that mean that establishing requirements for complex systems will always be a difficult technical and organisational problemL3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 21
  22. 22. Requirements change • System requirements reflect the world outside of the system. As this is constantly changing then the requirements will inevitably also change – Technology changes – Organisational changes – Market changes – Economic changes – Political and legal changes • It is often difficult to understand the implications of changes for the requirements as a wholeL3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 22
  23. 23. Stakeholder perspectives Technical perspectiveSocial perspective Objects Functions Roles ...Certification The problem and Customerperspective the required system perspectiveUser perspective Interactions Usability Management perspectiveL3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 23
  24. 24. Stakeholder uncertainty • Key stakeholders have other jobs to do! – Developing detailed requirements for future systems often cannot be given a high priority by the senior people who will be affected by these requirements. – They therefore are unable to express their requirements except as vague, high-level descriptionsL3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 24
  25. 25. How good are the requirements? • There are no objective ways to compare alternative sets of requirements – The impact of a system on a business is very hard to understand so therefore we cannot tell which might be the „best‟ system for any particular businessL3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 25
  26. 26. Process variability • The level of detail required in a requirements specification differs greatly depending on the type of product that is being developed – A railway signalling system is a very detailed specification that can be validated by authorities outside of the organisation procuring the software – A computer game specification is a storyboard with pictures and examples • They use completely different processes involving different types of people to derive these specifications • Scope for process standardisation and support is therefore limitedL3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 26
  27. 27. Politics and people • Many system requirements are influenced by the politics in an organisation. Decisions on requirements are not made on a rational basis but are made because of the personal goals of stakeholders • Requirements engineers may not understand the politics and, even when they do, they may not be able to challenge the „political‟ requirements • People providing requirements for a system may not be convinced that the system is necessary or may feel that other systems should have a higher priority. They may actively or passively refuse to cooperate in the requirements engineering processL3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 27
  28. 28. Summary • Requirements engineering is a key component of system development processes. • If we pay attention to requirements, we reduce later problems in system development and operation • Requirements engineering will always be difficult because the requirements are reflections of a rapidly changing business environmentL3 - Requirements Engineering, Critical Systems Engineering, 2011 Slide 28
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×