1. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 1 Chapter Three Requirements Engineering Software Engineering Objectives Be able to define requirements engineering Be able to structure a requirements document Be able to write verifiable functional and non-functional requirements Be able to describe the evolution of requirements Be able to create UML use-case descriptions Be able to draw UML use-case diagrams

2. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 2 Requirements engineering  The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed  What is a requirement? It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification Requirements may serve a dual function » May be the basis for a bid for a contract - therefore must be open to interpretation » May be the basis for the contract itself - therefore must be defined in detail » Both these statements may be called requirements

3. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 3 Requirements definition/specification  Requirements definition A statement in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers  Requirements specification A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor. For customers + developers  Software specification A detailed software description which can serve as a basis for a design or implementation. Written for developers

4. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 4 Problems with requirements definition  Hard to anticipate the effects that the new system will have on the organisation  Different users have different requirements and priorities.  System end-users and organisations who pay for the system have different requirements  Prototyping often required to clarify requirements  Natural language problems

5. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 5 How are requirements elicited?  Interviews Gives best information expensive  Questionnaires Good if many people involved especially if dispersed Tend to have poor responses  Observation Accurate if done well expensive  Searching Limited information Tends not to reveal potential problems

6. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 6 The requirements document  The requirements document is the official statement of what is required of the system developers  Should include both a definition and a specification of requirements  It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it

7. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 7 Requirements document structure  SECTION 1: Introduction purpose (including audience) Scope (what the product does/does not), benefits, obectives definitions, acronyms References Overview of Document  SECTION 2: Overall Description Product Perspective - How product relates to other systems Product Functions – high level description of each function User Characteristics Constraints. E.g. Hardware, safety, standards etc Assumptions

8. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 8 Requirements document structure  SECTION 3: Specific Requirements Minimum » Inputs » Outputs » All functions performed in response to inputs and outputs Complete List » External Interfaces (Names, description, source, valid range, unit, » Functions u actions that take place u “The system shall…” u Specific detail of each function – see form based requirements specification » Performance Requirements » Database Requirements » Design Constraints e.g. standards » Non-functional requirements (more about these later)

9. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 9  SECTION 3 continued Organisation of the SECTION 3 »By system mode u Training, normal, emergency »By user class By objects By feature By stimulus (Especially real-time systems e.g. pressure change) By response (everything to do with a certain output e.g. producing invoices)  APPENDICES E.g. sample inputs, cost analyses, user surveys, background information  INDEX

10. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 10 Example 1:

11. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 11 Example 2:

12. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 12 Requirements Specification - good practice  Use a form-based approach describe each function in a separate form

13. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 13 Pre & Post conditions  pre-condition (what must be true for the function to execute correctly)  post-condition (what is guaranteed to be true after the function executes)  Example: A merge function may be specified as follows: merge(item1:array,item2:array): newArray  Pre SizeOf(Item1)>0, SizeOf(Item2)>0, (both arrays have at least one element) item1[i]<item1[i+1], 1<i<noOfItems1 (in order) item2[i]<item2[i+1], 1<i<noOfItems2 (in order)  Post SizeOf(newArray)= SizeOf(Item1)> + SizeOf(Item2) newArray[i] < newArray[i+1], 1<i< SizeOf(newArray)  These are all testable!

14. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 14 Non-functional requirements  Define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc.  Process requirements may also be specified mandating a particular CASE system, programming language or development method  Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless  Typically: Reliability, Security, Availability, Maintainability, Portability, Performance

15. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 15 Requirements Verifiability  Requirements should be written so that they can be objectively verified  The problem with this requirement is its use of vague terms such as ‘errors shall be minimised” The system should be easy to use by experienced controllers and should be organised in such a way that user errors are minimised. » The error rate should be quantified Experienced controllers should be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users should not exceed two per day.

16. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 16 Non-functional requirements measures

17. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 17 UML - Use-Case Modelling  Use-case models describe externally the visible behavior of a system  Provides a view of the users of the system and the functions that the system must perform  Use-cases are initiated by users or systems called Actors  An actor represents anything that needs to interact with the system to exchange information – it may be a role a user plays or another system.  The actor initiates system activity, a use case, for the purposes of completing some task.  If an external party initiates the input, it is considered an actor Potential human users of the system, identify their roles Interactions with external systems  Use-case diagrams are used primarily during the requirements analysis stage  define the complete functionality of a system from a user perspective

18. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 18 Example: Diagram editor tool  From “Practical Object Oriented Design with UML’– Mark Priestly  Users create and edit drawings composed of lines, rectangles, ellipses and text.  Tools control the operation of the editor. Exactly one tool is active at a time.  There are 2 kinds of tool: selection tools and creation tools. With the selection tool active, the use can select drawing elements with the cursor »More than one element can be selected and manipulated as if they were one »The current selection is displayed visually by showing control points for the elements. Control points can be dragged to change the element shape When the creation tool becomes active, there is no current selection »On creation of an element it becomes the current selection »Text Element u The text creation tool changes the cursor to an I beam and the user can click this on the screen and start typing at that point u The text creation tool is no longer active once the user clicks outside the text element u The control points for a text element are its 4 corners – dragging this changes the region

19. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 19 Other Creation tools »Lines, rectangles ellipses »In these cases the cursor becomes a crosshair »MouseDown starts to create the object, Mouseup completes up »MouseDown sets the start point of the element, Mouseup the end point »Line – start point where MouseDown, end point at MouseUp. These points are also the control points »Rectangle – top left point where MouseDown, bottom right point at MouseUp. These points and the other corners become the control points »Ellipse – draws an ellipse to fit inside the rectangle drawn as with the rectangle tool. The rectangle does not appear, but its corners form control points for the ellipse

20. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 20 Use Case Diagram  Use Case diagram summarises all the use cases and actors in the system  Where necessary, scenarios are developed for the use cases  Use-cases are described only in terms of the services they offer to external actors. The internal details of precisely how this external behavior is to be achieved is represented using logical models e.g Class Diagrams.  They are not directly object- oriented

21. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 21 Example Use case  Creating New Diagrams  Lets suppose the editor gives the user a workspace within which one diagram can be displayed at a time.  On creation of a new diagram this workspace is empty (any existing diagrams are hidden  Users can choose which diagram to view form those that are open

22. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 22 Use-Case flow of Events  For each use-case identified, a use-case flow of events must be documented. This is a step by step description starting with the actor that initiated the use-case until the end of the event.  This can be done in textual prose. Good practice: use a standard template for the creation of the flow of events document  At first only the normal course of events are described, but as analysis progresses, more detail is added and alternative flows are added.

23. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 23 Use-Case Flow of Events for Create Diagram Use-Case

24. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 24 Use-Case Flow of Events for Create New Rectangle Use-Case

25. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 25 Use-Case Flow of Events for Create New Graphical Element Use-Case  BUT isn’t ellipse and line creation very similar to rectangle  About identifying two points  YES – lets use a general version instead i.e. Graphical Element G. element appropriate G. element

26. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 26 Use-Case Flow of Events for Create New Text Element Use- Case  This is different - but still has some common events as create graphical element  Create Element is a generalisation  Create Graphical Element and Create Text Element are specialisations of Create Element

27. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 27 Example Use Case – Select Element

28. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 28 Example Use Case – Delete Element  Suppose the user selects an item, then presses a delete button on the keyboard or toolbar  There is only a small bit of extra functionality here  Dashed arrow = UML dependency  > label indicates the stereotype of the dependency I.e. that Delete Element includes the use case Select Element Delete

29. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 29 Example Use Case – Moving an Element  Moving an element has a lot of the functionality of Select Element but does more  We can extend a use case  The base use case – Select Element must contain an extension point indicating where the the Move Element use case takes over and a condition saying when it should be extended I.e. when the user moves the mouse

30. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 30 Full Use Case Diagram

31. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 31 Generalisation between actors  Suppose our diagram tool operates in a shared environment and only Administrators can delete elements

32. Dr D. Greer, Queens University Belfast (Email:des.greer@qub.ac.uk)Chapter Three 32 Chapter Three Requirements Engineering Software Engineering Objectives Be able to define requirements engineering Be able to structure a requirements document Be able to write verifiable functional and non-functional requirements Be able to describe the evolution of requirements Be able to create UML use-case descriptions Be able to draw UML use-case diagrams