1. Requirements Analysis Requirements Engineering (CI 2323) Daniel Siahaan

2. Content Introduction to Requirements Engineering Add-on: Scenario Feasibility Studies Requirements Elicitation Creativity Thinking Requirements Analysis Requirements Specification Requirements Validation

3. Requirements analysis Sometimes called requirements elicitation or requirements discovery Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints May involve stakeholders: end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc.

4. Requirements Analysis Acquire understanding about the problem domain characteristics and problem to find the solution It is an information-acquiring, -collating, and –structuring process through which one attempts to understand all the various parts of a problem and their relationships. Basic Issues: –How to effectively elicit a complete set of requirements from the customer or other sources? –How to decompose the problem into intellectually manageable pieces? –How to organize the information so it can be understood? –How to communicate about the problem with all the parties involved? –How to resolve conflicting needs? –Ho to know when to stop?

5. System models Different models may be produced during the requirements analysis activity Requirements analysis may involve three structuring activities which result in these different models –Partitioning. Identifies the structural (part-of) relationships between entities –Abstraction. Identifies generalities among entities –Projection. Identifies different ways of looking at a problem Using modeling techniques, e.g. UML

6. The requirements analysis process

7. Methods for Requirements Analysis Structured Analysis Object Oriented Analysis Problem Domain Oriented Analysis Viewpoint Oriented Analysis

8. Structured Analysis Centered upon modeling the pre-existing system –Process –Data flow –Structure of data stored Weakness: –Downplay the study of the problem domain –Requirements are specified in term of idesign –Lack of sharp boundary between analysis and design encourage premature idesign –Functional specification is absent –Ill-suited for certain (not rarely) types of application

9. Object Oriented Analysis It’s not really an analysis: –It requires pre-existing requirements document and behaviour specification. High-level, architectural, design of the solution system. OOA Outline: –Identify object classes within the problem domain –Define the attribute and methods of those classes –Define the behaviour of those classses –Model the relationships between those classes

10. Object Oriented Analysis Three perspective of class model –Specification (i.e. interface classes) –Conceptual (i.e. problem domain classes – related to analysis) –Implementation (i.e. related to internal design)

11. Problem Domain Oriented Analysis Centered on modeling the problem context –Problem frames: capture significantly more information about the problem domain Less modeling, more description, procedure: –Collect basic information and develop problem frame(s) to establish the type of the problem domain –Collect further detail and develop description of the relevant characteristics of the problem domain –Collect and document the requirements for the new system

12. Problem Domain Oriented Analysis Type of problem domain: –Workpiece system – perform directed operations upon objects that exist only within the system –Control system – control the behavior (required- commanded) of part of the problem domain –Information system – provide information (automatically- responsively) about the problem domain –Transformation system – transform input data in a particular format into output data in a corresponding, particular format –Connection system – maintain correspondence between sub- domains that are not directly connected

13. Viewpoint-oriented analysis Stakeholders represent different ways of looking at a problem or problem viewpoints –different types of stakeholders –different views among stakeholders of same type This multi-perspective analysis is important as there is no single correct way to analyse system requirements

14. Multiple problem viewpoints

15. Autoteller system The example used here is an auto-teller system which provides some automated banking services I use a very simplified system which offers some services to customers of the bank who own the system and a narrower range of services to other customers Services include cash withdrawal, message passing (send a message to request a service), ordering a statement and transferring funds

16. Extra Assignments Study Literature: VORD –Contents (5-6 pages, 11p, 1.5space): Overview (What, Why, and How) Advantage – Disadvantage Practical Approach –Sources: G. Kotonya and I. Sommerville, "Requirements Engineering with Viewpoints", Software Eng. Journal 1996; 11(1): 5-11 I Sommerville and P Sawyer, “ Viewpoints: Principles, Problems, and a Practical Approach to RE ”, Cooperative System Engineering Group, Technical Report. 1997. Finkelstein et.al., “ Requirements Engineering Through Viewpoints ”, Departement of Computing, Imperial College, 2000. –Due Date: April 29 th, 2005 –Discussion Date: May 17 th, 2005

17. Autoteller viewpoints Bank customers Representatives of other banks Hardware and software maintenance engineers Marketing department Bank managers and counter staff Database administrators and security staff Communications engineers Personnel department

18. Types of viewpoint Data sources or sinks –Viewpoints are responsible for producing or consuming data. Analysis involves checking that data is produced and consumed and that assumptions about the source and sink of data are valid Representation frameworks –Viewpoints represent particular types of system models. These may be compared to discover requirements that would be missed using a single representation. Particularly suitable for real-time systems Receivers of services –Viewpoints are external to the system and receive services from it. Most suited to interactive systems

19. External viewpoints Natural to think of end-users as receivers of system services Viewpoints are a natural way to structure requirements elicitation It is relatively easy to decide if a viewpoint is valid Viewpoints and services may be sued to structure non-functional requirements

20. The VORD method

21. VORD standard forms

22. Viewpoint identification

23. Viewpoint service information

24. Viewpoint hierarchy

25. Customer/cash withdrawal templates

26. Method advantages/disadvantages Methods impose structure on the requirements analysis process May be supported by CASE tools Can be applied systematically and can lead naturally to design However, forces system modelling using a computational framework Methods fail to adequately provide for the description of human activities

27. System contexts The boundaries of the system must be established to determine what must be implemented These are documented using a description of the system context. This should include a description of the other systems which are in the environment Social and organisational factors may influence the positioning of the system boundary

28. Auto-teller system context

29. Social and organisational factors Software systems are used in a social and organisational context. This can influence or even dominate the system requirements Social and organisational factors are not a single viewpoint but are influences on all viewpoints Good analysts must be sensitive to these factors but currently no systematic way to tackle their analysis

30. Ethnographic analysis A social scientists spends a considerable time observing and analysing how people actually work People do not have to explain or articulate their work Social and organisational factors of importance may be observed Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models

31. Key points Requirements analysis requires domain understanding, requirements collection, classification, structuring, prioritisation and validation Complex systems should be analysed from different viewpoints Viewpoints may be based on sources and sinks of data, system models or external interaction

32. Key points Structured methods may be used for requirements analysis. They should include a process model, system modelling notations, rules and guidelines for system modelling and standard reports The VORD viewpoint-oriented method relies on viewpoints which are external to the system The boundaries between a system and its environment must be defined Social and organisational factors have a strong influence on system requirements