1. CC20O7N Software Engineering 1 CC2007N Software Engineering 1 Introduction to Requirements Engineering/Analysis

2. CC20O7N Software Engineering 1Contents 1.Introduction 2.Requirements engineering/analysis tasks 3.Systems modelling paradigms: 3.1structured/conventional 3.2object-oriented

3. CC20O7N Software Engineering 1Introduction Requirements engineering helps software engineers to better understand the problem they are to solve. Who does it? Software engineers (system analysts) and other project stakeholders e.g. managers, customers, end-users, etc. Why is it important? It is important to understand what the customer wants.

4. CC20O7N Software Engineering 1 Introduction (cont.) What are the steps? –Inception –Elicitation –Elaboration –Negotiation –Specification –Validation What is the work product? All project stakeholders should be provided with a written understanding of the problem e.g. user scenarios, functions and features lists, analysis models, etc.

5. CC20O7N Software Engineering 1 Introduction (cont.) How do I ensure that I’ve done it right? All work products are reviewed with the customer and end- users to ensure that what you have learned is what they really meant. Requirements engineering can be viewed as ‘a bridge to design and construction/implementation’.

6. CC20O7N Software Engineering 1 Three Categories of Requirements ‘Functional’ requirements - traditionally refer to WHAT the system must do. Non-functional requirements - aspects of the system that are concerned with HOW well it provides the functional requirements e.g. performance criteria, anticipated volumes of data, security considerations, etc (i.e. constraints). Usability requirements - to ensure that there is a good match between the system and both the users and the tasks they will undertake when using it.

7. CC20O7N Software Engineering 1Usability An attempt to qualify user-friendliness and can be measured in four characteristics: –The physical and/or intellectual skill required to learn the systems –The time required to become moderately efficient in the use of the system –The net increase in productivity measured when the system is used by someone who is moderately efficient –A subjective assessment of users attitudes towards the systems.

8. CC20O7N Software Engineering 1 Requirements Engineering Tasks Inception – a task that defines the scope and nature of the problem Elicitation – a task that helps the customer to define WHAT is required Elaboration – basic requirements are refined and expanded. This task involves MODELLING Negotiation – ‘conflicting’ requirements must be ‘resolved’ and the following questions answered: –what are the priorities –what is essential –when is it required? –etc.

9. CC20O7N Software Engineering 1 Requirements Engineering Tasks (cont.) Specification – the problem is specified in some manner e.g. a specification can be a written document, a set of graphical models, a prototype, or any combination of these. Validation – the work products are assessed for quality to ensure that requirements are unambiguous, complete, consistent, etc.

10. CC20O7N Software Engineering 1Inception Identifying the Stakeholders – people who benefit in a direct or indirect way from the system which is being developed. Recognizing Multiple Viewpoints (of stakeholders) Working towards Collaboration – to identify requirements on which all stakeholders agree and requirements causing some ‘conflicts’ among stakeholders. First questions: to identify stakeholders, to identify measurable benefits of the system. Next questions: to gain a better understanding of the problem.

11. CC20O7N Software Engineering 1Elicitation Before requirements can be analysed, modelled, or specified they must be gathered through an elicitation process. There are many ‘traditional’ requirements elicitation (or fact finding) techniques: background reading, interviewing, observation, document sampling, questionnaires. They have their advantages and disadvantages (see below) There are also some ‘modern’ requirements elicitation techniques e.g. JAD (Joint Application Design) sessions, Collaborative Requirements Gathering (see Pressman) etc.

12. CC20O7N Software Engineering 1 Joint Application Design (JAD) JAD - an information gathering technique that allows the project team, users, and management to work together to identify requirements. JAD is a structured process in which 10 to 20 users meet together under the direction of a facilitator skilled in JAD techniques. One or two scribes assist the facilitator by recording notes, making copies etc.

13. CC20O7N Software Engineering 1 JAD (cont.) JAD sessions can run from as little as half a day to several weeks JAD sessions are usually designed and structured using the same principles as interviews, follow a formal agenda and have ground rules that define appropriate behaviour The JAD facilitator performs three key functions: –to ensure that the group sticks to the agenda –to help the group to understand the technical terms and jargon –to record the group’s input on a public display area The facilitator must remain neutral at all times and simply help the group through the process.

14. CC20O7N Software Engineering 1 Background Reading Suitable sources of information: –company reports –charts –policy manuals –job descriptions –documentation of existing systems –etc.

15. CC20O7N Software Engineering 1 Background Reading Advantages and Disadvantages It helps to get an understanding of the organization BEFORE meeting the people who work there. (+) It allows to prepare for other types of fact finding exercises. (+) The documentation may provide formally defined requirements for the current system. (+) written documents often do not match up to reality. (e.g. out of date, reflect ‘theory’ rather than practice) (-)

16. CC20O7N Software Engineering 1Interviewing A system analysis interview is a STRUCTURED meeting between the analyst and a member of staff of the organization being investigated. The degree of structure may vary from a fixed set of questions to open-ended covering certain topics. A series of interviews can range across different areas of the interviewee’s work or to investigate that work in more and more detail.

17. CC20O7N Software Engineering 1 Interviewing Advantages and Disadvantages Personal contact allows the analyst to be responsive and adapt to what the user/sponsor says. (++) Probing in greater depth about the user’s work (+) If the interviewee has nothing to say, the interview can be terminated (+) Time-consuming and costly (-) It requires the analyst to work after the meeting (-) Subject to bias if the interviewer has a closed mind about the problem (-)

18. CC20O7N Software Engineering 1Observation Watching people carrying their work in a natural setting allows to observe the normal aspects of a job as well as exceptional situations (which the system will have to cope with!). Observation also allows the analyst to see what information people use to carry out their jobs (is all the necessary information available, at hand?) Observation can provide quantitative data about typical times to perform a task, task duration etc.

19. CC20O7N Software Engineering 1 Observation Advantages and Disadvantages It provides first hand experience of the current system operation. (+) Data collected in real time, so have a high level of validity. (+) Can be used to verify information from other sources. (+) Most people do not like being observed and are likely to behave differently. (-) There may be logistical problems for the analyst ( e.g. if staff to be observed work shifts, etc). There may also be ethical problems if sensitive private or personal data are involved.

20. CC20O7N Software Engineering 1 Document Sampling Document sampling can be used in two different ways: –copies of blank and completed documents are used to determine the data and information used by staff, input to and outputs from processes they carry out –statistical analysis of documents will help to estimate volumes of data to be held, to be input, and output.

21. CC20O7N Software Engineering 1 Document Sampling Advantages and Disadvantages It can be used to gather quantitative data, such as the average number of lines on an invoice, etc. (+) It can be used to find out about error rates in paper documents (+) If the system will change dramatically, existing documents may not reflect how it will be in future (-)

22. CC20O7N Software Engineering 1Questionnaires They consist of a series of written questions. The range of replies is usually limited (e.g. Yes or No). Some questions do not have a fixed number of responses, and must be left open-ended for the respondents to enter what they like.

23. CC20O7N Software Engineering 1 Questionnaires Advantages and Disadvantages An economical way of gathering data from a large number of people. (++) If the questionnaire is well designed, then the results can be analysed easily. (possibly by computer) (+) Good questionnaires are difficult to construct. (-) No automatic mechanism for follow up or probing more deeply. (-) Postal questionnaires suffer from low response rate. (-)

24. CC20O7N Software Engineering 1Elaboration Elaboration is an analysis modelling action that is composed of a number of modelling and refinement tasks. There are two broad approaches to modelling (or two modelling paradigms): structured/conventional and object- oriented. Both approaches are briefly discussed below. –Structured approach is reviewed in Week 3 (as it was covered in CS2E23). –Object-oriented approach is covered in BS2011.

25. CC20O7N Software Engineering 1Negotiation Ideally, the previous steps should determine customer requirements in sufficient detail to proceed to design. In reality, the customer and the developer enter into a process of negotiation, where the customer may be asked to balance functionality, performance and other product characteristics against cost and time to market. The objective of this negotiation is to develop a project plan that meets the needs of the customer while at the same time reflecting the real-world constraints (time, people, budget) that have been placed on the software team. The best negotiations strive for a ‘win-win’ result!

26. CC20O7N Software Engineering 1Specification The specification is the final work product produced by the requirements engineer (analyst). It serves as the foundation for subsequent software engineering activities (design, implementation, etc). It describes the function and performance of a computer-based system and the constraints that will govern its development. The specification usually combines text, graphical models, etc.

27. CC20O7N Software Engineering 1Validation Requirements validation examines the specification to ensure that all requirements have been stated unambiguously, that inconsistencies, omissions, and errors have been detected and corrected, and that the work product conforms to the standards established for the process, the project, and the product. The primary requirements validation mechanism is the formal technical review.

28. CC20O7N Software Engineering 1 Systems Modelling Paradigms Structured/’conventional’ paradigm –A system is viewed as a ‘collection’ of processes which operate on data entities (‘stored’ in data stores/files/database). –These processes correspond to various functional requirements, e.g. when we model a typical library system we are going to have such processes: Borrow Book, Return Book, Reserve Book etc. These processes operate on data entities Book, Loan, Reservation, etc.

29. CC20O7N Software Engineering 1 Structured/’Conventional’ View of a System

30. CC20O7N Software Engineering 1 Systems Modelling Paradigms (cont.) Object-oriented paradigm: –A system is viewed as a ‘collection’ of objects (class instances). Each object/class encapsulates its attributes (i.e. data) and operations. –Functional requirements (i.e. system functions) are ‘realised’ by collaborating objects. For example when we model a typical library system we are going to have such classes of objects: Book, Loan, Reader, etc. Function ‘Borrow Book’ will be ‘realised’ by corresponding operations of Book Object, Loan Object and possibly Reader Object. All these objects will collaborate to ‘realise’/process ‘Borrow Book’.

31. CC20O7N Software Engineering 1 Object Oriented ‘View’ of a System

32. CC20O7N Software Engineering 1 What Do We Normally Model Using Structured/Conventional Methods and Techniques? Functional requirements (to specify system’s functionality) e.g. using DFDs (processes, data flows, data stores, terminators/external entities) Data requirements (to specify system’s data) e.g. using ERDs (Logical Data Structures) (entities and relationships) Also we should specify which entities are manipulated/processed by which processes!!

33. CC20O7N Software Engineering 1 How Do We Specify ( in SSADM ) Which Entities Are Manipulated/Processed by Which Processes? Two modelling techniques are used to specify ‘connections’ between PROCESSES (in fact EVENTS that ‘trigger’ these processes) and ENTITIES. Effect Correspondence Diagram (ECD) shows which entities are affected by a given event (or a process ‘triggered’ by this event). Entity Life History (ELH) shows all of the events that can affect a given entity.

34. CC20O7N Software Engineering 1 What Do We Normally Model Using Object-Oriented Methods and Techniques? Functional requirements (to specify system’s functionality) e.g. using Use cases and Use case diagrams (they will be discussed in BS2011!) Data requirements (to specify system’s data) e.g. using Class diagrams (these will be discussed in BS2011). Please note that classes encapsulate attributes/data and OPERATIONS! Therefore fully developed class diagrams show both! Also we should specify which use cases are ‘realised’ by which objects

35. CC20O7N Software Engineering 1 How Do We Specify ( in UML ) Which Use Cases Are ‘Realised’ by Which Objects? The main UML techniques to specify ‘contribution’ of objects to ‘realisation’ of use cases are Object Interaction Diagrams. In fact there are two types of interaction diagrams : sequence diagrams and collaboration diagrams (both types will be discussed in BS2011!)

36. CC20O7N Software Engineering 1Summary Requirements engineering/analysis tasks Systems modelling paradigms: –Structured/Conventional –Object-Oriented