L3 Requirements Eng Overview

2,170
-1

Published on

A general overview of systems requirements engineering

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

No Downloads
Views
Total Views
2,170
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
86
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

L3 Requirements Eng Overview

  1. 1. Requirements Engineering<br />Professor Ian Sommerville<br />St Andrews University<br />
  2. 2. Objectives<br />To explain what is meant by a requirement and requirements engineering<br />To present the requirements engineering process from a number of different viewpoints<br />To discuss problems of requirements engineering, requirements engineering methods and challenges to traditional approaches of requirements engineering<br />
  3. 3. Introduction<br />Frequently asked questions about requirements engineering<br />
  4. 4. What are requirements?<br />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. <br />They may be:<br />a user-level facility description, <br />a detailed specification of expected system behaviour,<br />a general system property, <br />a specific constraint on the system,<br />information on how to carry out some computation,<br />a constraint on the development of the system.<br />
  5. 5. Examples of requirements<br />Functional requirements<br /> “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”<br />Non-functional requirements<br /> “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”<br />Domain requirements<br /> “The system shall implement patient privacy provisions as set out in the 1998 Data Protection Act”<br />
  6. 6. What is requirements engineering?<br />Requirements engineering covers all of the activities involved in discovering, documenting, and maintaining a set of requirements for a computer-based system.<br />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.<br />
  7. 7. Are requirements important?<br />European Software Process Improvement Training Initiative (1996)<br />“The principal problem areas in software development and production are the requirements specification and the management of customer requirements”<br />In a study of errors in embedded systems, it was found that:<br />“... difficulties with requirements are the key root-cause of the safety-related software errors that have persisted until integration and system testing”<br />
  8. 8. What happens if the requirements are wrong?<br />The system may be delivered late and cost more than originally expected.<br />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.<br />The system may be unreliable in use with regular system errors and crashes disrupting normal operation.<br />If the system continues in use, the costs of maintaining and evolving the system are very high.<br />
  9. 9. Why is requirements engineering difficult?<br />Businesses operate in a rapidly changing environment so their requirements for system support are constantly changing. <br />Multiple stakeholders with different goals and priorities are involved in the requirements engineering process.<br />System stakeholders do not have clear ideas about the system support that they need.<br />Requirements are often influenced by political and organisational factors that stakeholders will not admit to publicly.<br />
  10. 10. Can we get the requirements for an LSCITS ‘right’?<br />Almost certainly not. The complexity of the interactions within an LSCITS and between the LSCITS and the wider STS is such that the notion of ‘correct’ requirements does not really make sense<br />LSCITS requirements will inevitably be:<br />An uneasy compromise between the requirements of different sets of LSCITS stakeholders<br />Out of date as soon as they are agreed<br />Nevertheless, we need requirements to serve as a basis for discussion about the system features and to define what is to be implemented.<br />Progress without requirements is practically impossible<br />
  11. 11. Requirements engineering processes<br />Different views of the processes involved in requirements engineering<br />
  12. 12. The systems engineering process<br />
  13. 13. RE process context<br />
  14. 14. RE process inputs and outputs<br />
  15. 15. RE process activities<br />
  16. 16. RE process iteration<br />
  17. 17. Requirements engineering problems<br />Fundamental issues that mean that establishing requirements for complex systems will always be a difficult technical and organisational problem<br />
  18. 18. Requirements change<br />System requirements reflect the world outside of the system. As this is constantly changing then the requirements will inevitably also change<br />Technology changes<br />Organisational changes<br />Market changes<br />Economic changes<br />Political and legal changes<br />It is often difficult to understand the implications of changes for the requirements as a whole <br />
  19. 19. Stakeholder perspectives<br />Technical perspective<br />Objects<br /> Functions<br /> Roles ...<br />Social perspective<br />Certification<br />perspective<br />Customer<br />perspective<br />The problem and <br />the required system<br />User perspective<br />Interactions<br /> Usability<br />Management perspective<br />
  20. 20. Stakeholder uncertainty<br />Key stakeholders have other jobs to do!<br />Developing detailed requirements for future systems often cannot be given a high priority by the senior people who will be affected by these requirements.<br />They therefore are unable to express their requirements except as vague, high-level descriptions<br />There are no objective ways to compare alternative sets of requirements<br />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 business<br />
  21. 21. Process variability<br />The level of detail required in a requirements specification differs greatly depending on the type of product that is being developed<br />A railway signalling system is a very detailed specification that can be validated by authorities outside of the organisation procuring the software<br />A computer game specification is a storyboard with pictures and examples<br />They use completely different processes involving different types of people to derive these specifications<br />Scope for process standardisation and support is therefore limited<br />
  22. 22. Politics and people<br />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<br />Requirements engineers may not understand the politics and, even when they do, they may not be able to challenge the ‘political’ requirements<br />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 process<br />
  23. 23. Requirements methods and tools<br />Techniques and CASE tools that may be used in the requirements engineering process<br />
  24. 24. Scenarios<br />What are scenarios?<br />Scenarios are descriptions of typical ways that a particular end-user task might be carried out. By understanding what is done then requirements for computer support can be developed<br />Applicability<br />They are primarily useful during requirements elicitation<br />Maturity<br />This approach to requirements elicitation is becoming increasingly widely used. Use-cases in the UML process are closely related to scenarios<br />Problems<br />Time consuming to develop scenarios<br />Focused on end-user stakeholders<br />
  25. 25. Viewpoints<br />What are viewpoints<br />Ways of identifying stakeholders and organising the requirements from different stakeholders<br />Applicability<br />Different types of viewpoint have been proposed that are applicable during requirements elicitation and the development of detailed system requirements<br />Maturity<br />Methods have existed for many years but have not been extensively used<br />Problems<br />Too many viewpoints lead to an unmanageable amount of data<br />Lack of tool support<br />
  26. 26. Structured analysis methods<br />What are structured analysis methods<br />Methods of deriving detailed models of the problem or of the system to be developed in some well-defined notation<br />Applicability<br />Methods of structured analysis, such as object-oriented analysis, are applicable when developing detailed requirements from user requirements<br />Maturity<br />These are the most mature techniques for requirements analysis<br />Problems<br />End-users often do not relate to the models or have time to be involved in the process of model development<br />
  27. 27. Tools for requirements engineering<br />Tool support for requirements engineering is mostly limited to two areas<br />Requirements analysis using structured methods<br />Developing a set of user requirements into detailed system requirements that are expressed using different system models <br />UML tools for object-oriented analysis<br />Requirements management<br />Supporting the process of managing requirements change<br />DOORS for managing text-based requirements<br />The critical areas of requirements elicitation, understanding and negotiation are not well-supported by CASE tools.<br />
  28. 28. Requirements management tool<br />
  29. 29. Requirements challenges<br />Some challenges for requirements engineering in the 21st century<br />
  30. 30. E-commerce and globalisation<br />E-commerce systems that are designed to serve a global customer base have new types of requirement<br />Aesthetic requirements<br />What image is the company trying to convey through its software systems?<br />Marketing requirements<br />How can the system be used to reinforce the brand and the marketing goals of the company?<br />Multicultural requirements<br />How can the system be designed to take into account different cultural traditions and sensitivities?<br />
  31. 31. Accelerated system development<br />The need for organisations to be more responsive means that there is increasing pressure for faster delivery of all types of system<br />Increasing competition means that the business costs of delivering unsuitable systems are increasing<br />Therefore<br />The time to deliver requirements must be reduced<br />The requirements must be a better reflection of the business needs<br />
  32. 32. Off-the-shelf systems<br />Many business systems and an increasing number of other types of system are being developed by integrating existing off-the-shelf systems<br />How can we decide if an existing system meets a business need and what are the costs of using an existing system rather than developing detailed requirements for a custom system?<br />How can we decide whether or not the integration of several systems meets a set of requirements especially if these include security, performance and reliability requirements?<br />
  33. 33. Summary<br />Requirements engineering is a key component of system development processes. <br />If we pay attention to requirements, we reduce later problems in system development and operation<br />Requirements engineering will always be difficult because the requirements are reflections of a rapidly changing business environment<br />‘Traditional” requirements engineering processes will have to evolve for new types of software system and business needs<br />

×