Requirements engineering (1)

1. Requirements engineering (1) RE is the process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. The requirements themselves are the descriptions of the system services (functions) and constraints that are generated during the requirements engineering process. In other words, what does the customer want the system to do and how does the customer want the system to behave ! In practise, especially, with iterative SD methods, separating RE and design is not fully possible RE should focus on the WHAT and not on the HOW. The critical issue is to identify and represent the functions that the user requires and NOT how they might be implemented

2. Requirements engineering (2) Requirements engineering involves:- • Feasability studies • Requirements elicitation and analysis • Requirements validation • Requirements management

3. Requirements engineering (3) From: Sommerville (Software Engineering)

4. Requirements engineering (4) From: Sommerville (Software Engineering)

5. Requirements engineering (5) Often called “user requirement” A requirement description may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. This is inevitable as requirements may serve a dual function: • it may be the basis for dialogue with the clients/users and therefore must be • understandable by them • It may serve as a specification on which software design & implementation will • be based Often called “system requirement”

6. Requirements engineering (6) Example of user requirement (A library system where the user may need to access and view files of many different types (formats)): The system must provide a means of accessing and representing external files created by various tools. Example of system requirement: 1.1 The user should be provided with facilities to define the types of external files 1.2 Each external file type should have an associated tool which can be applied to the file 1.3 Each external file type should be represented as a separate specific icon on user’s display monitor 1.4 A facility should be provided for the icon representing a specific file type to be defined by the user 1.5 When a user selects an icon representing a specific file, the effect of this should be to apply the tool associated with this type of external file to the file represented by the selected icon

7. Requirements engineering (7) Client managers System users Contractor managers (if involved) Read by User requirements System engineers End-users System designers Software developers Read by System requirements

8. Requirements engineering (8) Types of Requirements: • Functional requirements • Statements of services the system should provide, how the system • should react to particular inputs and how the system should behave in • particular situations. • Non-functional requirements • constraints on the services or functions offered by the system • such as timing constraints, constraints on the development process, • standards, etc. (e.g response time, security, memory/storage constraints) • Domain requirements • Requirements that come from the application domain of the system • and that reflect characteristics of that domain. (e.g. a requirement to use • the terminology of the application area)

9. Requirements engineering (9) Examples of Requirements: • Functional requirement • The system should generate a list of students (sorted by Student ID) taking • a particular module if the user submits the appropriate module code. • Non-functional requirements • The system should not require more than 30 secs to start-up • The system should be able to search the database and retrieve details of • A specific student in no more than 1.5 sec. • The system should provide security for all electronic money transfers • Domain requirements • A commodity broking system should identify all commodities by the codes • used on the International Commodity Exchange and units of weight • measurements Should beas used by the ICE for each particular commodity

10. Requirements engineering (10) Requirements should be: Description of all facilities required • Complete • Consistent No conflict or contradictions in the description of system facilities In practice, this is very difficult to achieve

11. Requirements engineering (11) Requirements may interact! • Conflicts between different non-functional requirements are • common in complex systems: Take a system to control a spacecraft - • To minimise weight, the number of separate chips in the system should be • minimised. • To minimise power consumption, lower power chips should be used. • However, using low power chips may mean that more chips have to be used. • Which is the most critical requirement?

12. Requirements engineering (12) but Requirements may interact! • A more commonplace example: In a company trading goods - • SALES may want x number of all product items to be held in stock but • WAREHOUSE may request that no more than 1 item should be held in stock • for any product larger than 0.5 m3 while • FINANCE may require that the total value of all stock held should not exceed • €250,000 • Conflicting requirements can reflect political/territorial battles within an • organisation. • Resolutions are rarely simple and run a real risk of introducing a degree of • compromise into systems which will make them significantly sub-optimal.

13. Requirements engineering (13) Interviewer should not have preconceived ideas – no prompting interviewee with required answer Structured (closed) or unstructured (open) Requirements Gathering No interrogation or implied threats! Interviewing and/or Recording a user’s “story” (see Agile) Write interview report and confirm with interviewee Questionnaires Useful when opinions of hundreds of users needed Observation of work flows More accurate than interviews Examination of forms used by organisation Probably low % response Examination of previous reports Learn about system’s data and its transformation

14. Requirements engineering (14) • User requirements Representing requirements: • System requirements Narrative (written) English Often ambiguous so rarely used (but see Slide 6) • Program Design Language (Structured English) Brief instructions within “begin-end”, “if-then-else-endif”, “repeat-until” structures • Decision tables “Actors “ and their “roles” Graphical picture of sequence of messages between objects Use-case diagrams Where values of several conditions decide action to take Sequence diagrams Formal specification Formal specification (provable)

15. Requirements engineering (15) Embed precise English-language statements within structured program design statements Program Design Language (prev. Structured English) REPEAT UNTIL activate_switch is turned off reset all signal.values and switches; DO FOR alarm.type = smoke, fire, water, temp, burglar; READ address[alarm.type] signal.value; IF signal.value > bound[alarm.type] THEN phone.message = message[alarm.type] set alarm.bell to “on” for alarm.timeseconds PARBEGIN CALL alarm PROCEDURE WITH “on”, alarm.time in seconds; CALL phone PROCEDURE WITH message[alarm.type], phone.number; ENDPAR ELSE skip ENDIF ENDREPEAT

16. Requirements Engineering (16): Decision Trees Action Policy for Book Sales & Dispatch: <= 4 packages: 10% Educational Institution > 4 packages: 15% Other: 0% Order value <= €200: no insurance Order value > €200: Insure

17. Conditions Values Requirements Engineering (17): Decisions Tables Educational institution Y, N An online book sales company needs to specify what are the rules for sales orders to determine discounts and whether or not to charge insurance . No packages < 4 Y, N Order Value > €200 Y, N Note that a condition may have more than 2 values: Rules Conditions e.g. Educational institution Y N Y N Y N Y N “postal zone” could be - A = Ireland & UK - B = Rest of Europe - C = Rest of World therefore 3 values No packages < 4 Y Y N N Y Y N N Order Value > €200 Y Y Y Y N N N N Y Y Y Y 0% discount Actions 10% discount Y Y Look for – impossible rules; indifferent rules. (example on white board Y Y 15% discount Y Y Y Y Insure No. of rules = No. values for Condition 1 x No. values for Condition 2 …. x No. values for Condition n

18. Requirements engineering (18) Use Case Diagrams – Representing Process by Actors and their Roles Use Case Diagrams (part of UML) provide a means of representing required functionality by depicting part of a system in terms of actors (the “things” that the system interacts with) and use cases (the services or functions that the system should provide.) Use Case Diagrams are not intended to represent sequence, iteration or exception behaviour. Structured text specifications (PDL style) can be developed for each use case diagram. One use case diagram can be used to represent all the functions in a specific part of a system or else to represent all the functions relating to a single actor.

19. Requirements engineering (19) Use Case Diagrams Notation Use Case 4 is a more specialised instance of Use Case 3 Actor 2 is a more specialised instance of Actor 1 Use Case 5 is a special case of Use Case 2 The execution of Use Case 2 always includes the execution of Use Case 4

20. Requirements engineering (20) Use Case Diagram Example

21. Requirements engineering (21) Sequence Diagrams Sequence models are diagrams that represent the sequence of object Interactions that may take place for a particular subset of actors and objects

22. Requirements engineering (22) Formal specification (1) The Z specification language allows the description of a system (or part of) in terms of states and operations. In its simplest form a Z specification consists of : Given sets, data types, and constants State definition Initial state Operations Use of Z requires knowledge of set theory, functions and discrete mathematics

23. Requirements engineering (23) Formal specification (2)  Some definitions: Predicate A statement about something which returns a True or False result A schema (in Z) Variable declarations + list of predicates that constrain the possible values of the variables P The power set (the set of all subsets of a given set)  The intersection of 2 sets (the elements that they have in common) The union of 2 sets (all elements in both sets – without duplicates)   Is a member of a named set Also -  Is not a member of a named set ? = input variable  An operation which changes a state ? = output variable  Logical AND Logical OR  {set name}’ The new state of the set called {set name}

24. Requirements engineering (24) Formal specification (3) An elevator system has 4 subsets of the type Button: the floor buttons, the elevator buttons, buttons (the set of all buttons), and pushed (the set of all “on” buttons - buttons that have been pushed).

25. Requirements engineering (25) Formal specification (4) Declarations of data, state definitions 4 subsets of the power set Button The sets of floor_buttons and elevator_buttons have no common (shared) elements The sets of floor_buttons and elevator_ buttons constitute the set Button (From Schach, 2007, Object-Oriented & Classical Software Engineering)

26. Requirements engineering (26) Value of input(?) button must be member of set buttons AND input button is NOT a member of pushed button set AND set of pushed buttons is updated to include button? OR if button already a member of set of pushed buttons then the new state of pushed is the same as the old state Formal specification (5) (From Schach, 2007, Object-Oriented & Classical Software Engineering)

27. Requirements engineering (27) Formal specification (6) Z specification allows definition of data, preconditions, relationships between states and between sets, and postconditions. Correctness is provable mathematically. Software tools exist to prove the correctness of a specification in Z (or in other formal specification languages) Writing Z specifications forces the specifier to be extremely precise. As a result of this need for exactness, it has been found that Z-specified requirements have fewer ambiguities, contradictions and omissions than with Informal specifications. Therefore, using a formal specification method (such as Z) can have definite advantages even if “proving correctness” is not done.