Software engineering lec4

1. Requirements Software engineering lec4

2. Developing requirements • Start thinking about particular problem • Understand the problem • Domain analysis • Gather information • To describe the problem • To describe solution • How to gather and analyzing the problem

3. Domain analysis • Used to learn background information • Sufficient information • Good decision about: • Requirement analysis • Engineering process • Domain: general field of the problem business • Examples? • Ask the domain experts

4. Cont. • Gather information about the problem domain: • Ask experts • Books • Documentations • Interviewing • Brainstorming • You are not to be an expert in this domain • What are the goods when you do this:

5. Cont. • Faster development • Easy to communicate with the stakeholders • Better system • Analysis leads to better abstraction and hence improve designs • Anticipation of extension • More adaptable system • Future development • Emerging trends

6. Summary • It is useful to write a summary • Introduction • Glossary • General knowledge • Customer and user • The environment • Tasks and procedures • Competing software • Similarities across domain and organization • Do not write too much

7. Example: airlines reservation • What are the required information? • Flight scheduling • Fares • Ticketing • Booking • Study what: • Airline reservation business • Travel agents • Employees • Laws and rules for govern this business • What is competing for airlines systems • What currently available

8. Chapter 4: Developing requirements 4.3 Defining the Problem and the Scope A problem can be expressed as: • A difficulty the users or customers are facing, • Or as an opportunity that will result in some benefit such as improved productivity or sales. The solution to the problem normally will entail developing software A good problem statement is short and succinct

9. Chapter 4: Developing requirements Use-Cases describing how the user will use the system A use case is a typical sequence of actions that a user performs in order to complete a given task • The objective of use case analysis is to model the system … from the point of view of how users interact with this system … when trying to achieve their objectives. • A use case model consists of • a set of use cases • an optional description or diagram indicating how they are related

10. Chapter 4: Developing requirements Use cases • In general, a use case should cover the full sequence of steps from the beginning of a task until the end. • A use case should describe the user’s interaction with the system ... • not the computations the system performs. • A use case should be written so as to be as independent as possible from any particular user interface design. • A use case should only include actions in which the actor interacts with the computer.

11. Chapter 4: Developing requirements Scenarios A scenario is an instance of a use case • It expresses a specific occurrence of the use case • a specific actor ... • at a specific time ... • with specific data.

12. Chapter 4: Developing requirements How to describe as single use case A. Name: Give a short, descriptive name to the use case. B. Actors: List the actors who can perform this use case. C. Goals: Explain what the actor or actors are trying to achieve. D. Preconditions: State of the system before the use case. E. Description: Give a short informal description. F. Related use cases. G. Steps: Describe each step using a 2-column format. H. Postconditions: State of the system in following completion.

13. Chapter 4: Developing requirements Use case diagrams

14. Chapter 4: Developing requirements Extensions • Used to make optional interactions explicit or to handle exceptional cases. • By creating separate use case extensions, the description of the basic use case remains simple. • A use case extension must list all the steps from the beginning of the use case to the end. • Including the handling of the unusual situation.

15. Chapter 4: Developing requirements Generalizations • Much like superclasses in a class diagram. • A generalized use case represents several similar use cases. • One or more specializations provides details of the similar use cases.

16. Chapter 4: Developing requirements Inclusions • Allow one to express commonality between several different use cases. • Are included in other use cases • Even very different use cases can share sequence of actions. • Enable you to avoid repeating details in multiple use cases. • Represent the performing of a lower-level task with a lower-level goal.

17. Chapter 4: Developing requirements Example of generalization, extension and inclusion

18. Chapter 4: Developing requirements Example description of a use case

19. Chapter 4: Developing requirements Example (continued)

20. Chapter 4: Developing requirements Example (continued)

21. Chapter 4: Developing requirements Example (continued)

22. Chapter 4: Developing requirements Example (continued)

23. Chapter 4: Developing requirements The modeling processes: Choosing use cases on which to focus • Often one use case (or a very small number) can be identified as central to the system • The entire system can be built around this particular use case • There are other reasons for focusing on particular use cases: • Some use cases will represent a high risk because for some reason their implementation is problematic • Some use cases will have high political or commercial value

24. Chapter 4: Developing requirements The benefits of basing software development on use cases • They can help to define the scope of the system • They are often used to plan the development process • They are used to both develop and validate the requirements • They can form the basis for the definition of testcases • They can be used to structure user manuals

25. Chapter 4: Developing requirements Use cases must not be seen as a panacea • The use cases themselves must be validated • Using the requirements validation methods. • There are some aspects of software that are not covered by use case analysis. • Innovative solutions may not be considered.

26. Chapter 4: Developing requirements Some Techniques for Gathering and Analysing Requirements Observation • Read documents and discuss requirements with users • Shadowing important potential users as they do their work • ask the user to explain everything he or she is doing • Session videotaping Interviewing • Conduct a series of interviews • Ask about specific details • Ask about the stakeholder’s vision for the future • Ask if they have alternative ideas • Ask for other sources of information • Ask them to draw diagrams

27. Chapter 4: Developing requirements Gathering and Analysing Requirements... Brainstorming • Appoint an experienced moderator • Arrange the attendees around a table • Decide on a ‘trigger question’ • Ask each participant to write an answer and pass the paper to its neighbour Joint Application Development (JAD) is a technique based on intensive brainstorming sessions

28. Chapter 4: Developing requirements Gathering and Analysing Requirements... Prototyping • The simplest kind: paper prototype. • a set of pictures of the system that are shown to users in sequence to explain what would happen • The most common: a mock-up of the system’s UI • Written in a rapid prototyping language • Does not normally perform any computations, access any databases or interact with any other systems • May prototype a particular aspect of the system

29. Chapter 4: Developing requirements Gathering and Analysing Requirements... Use case analysis • Determine the classes of users that will use the facilities of this system (actors) • Determine the tasks that each actor will need to do with the system

30. Chapter 4: Developing requirements Defining the Scope Narrow the scope by defining a more precise problem • List all the things you might imagine the system doing • Exclude some of these things if too broad • Determine high-level goals if too narrow Example: A university registration system

31. Chapter 4: Developing requirements 4.4 What is a Requirement Requirement: A statement about the proposed system that all stakeholders agree must be made true in order for the customer’s problem to be adequately solved. • Short and concise piece of information • Says something about the system • All the stakeholders haveagreed that it is valid • It helps solve the customer’s problem A collection of requirements is a requirements document.

32. Chapter 4: Developing requirements Types of Requirements Functional requirements • Describe what the system should do Non-functional requirements • Constraints that must be adhered to during development

33. Chapter 4: Developing requirements Functional requirements • What inputs the system should accept • What outputs the system should produce • What data the system should store that other systems might use • What computations the system should perform • The timing and synchronization of the above

34. Chapter 4: Developing requirements Non-functional requirements All must be verifiable Three main types 1. Categories reflecting: usability, efficiency, reliability, maintainability and reusability • Response time • Throughput • Resource usage • Reliability • Availability • Recovery from failure • Allowances for maintainability and enhancement • Allowances for reusability

35. Chapter 4: Developing requirements Non-functional requirements 2. Categories constraining the environment and technology of the system. • Platform • Technology to be used 3. Categories constraining the project plan and development methods • Development process (methodology) to be used • Cost and delivery date • Often put in contract or project plan instead

36. Questions for this lecture • What is meant by requirement engineering? • Requirement engineering could be classified into different types list five ? • What is the different between functional and non-functional requirements? • If you are to develop a project involve in designing a system for ticket reservation. • List five (5) functional requirements for you system. • List five Non-functional requirements for your system.

37. Cont. • What is purpose of doing a domain analysis? • If you have been asked to improve a system for book store in your university. • Is your project a Greenfield project, and why? • Considering the four starting points in page 9. under which starting point, you can classify your project? • List four of the framework requirements in this project?

38. Cont. • What are the eight (8) elements to describe a use case? • Describe the following use cases: • Booking a ticket. • Canceling a booking in a flight • Adding a new book to the library • Student is taking a subject. (register for the subject)

39. Cont. • Draw a use case diagram for the examples in the last question. • In a student registration unit system: • Suggest three actors to this system • What are the proper information that could taken from the student to register for a new semester. • Write three pages as analysis documentation for your project.