Instructor: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department Object Oriented Analysis & Design Gathering Requirements

Instructor: Tasneem Darwish2 INTRODUCTION   The aim of the requirements phase is twofold:   Examine the business context: We need to clarify the reasons for wanting the software to be developed in the first place – if we can’t come up with good reasons, we shouldn’t write the software at all. When we’ve decided that we do want to produce a software system, we need to make sure that we understand the business and that our understanding matches that of our sponsors.   Describe the system requirements: This involves not only deciding on the functionality of the system but also detecting any constraints – performance, development cost, resources and so on.

Instructor: Tasneem Darwish3 INTRODUCTION   Before we even consider writing a piece of software, we must investigate the business in which the software will operate – without a thorough understanding of the business, we could hardly expect to produce something that would enhance that business   The term business is used here in its loosest sense: think of ‘business’ as ‘problem domain’.

Instructor: Tasneem Darwish4 INTRODUCTION   Once we have understood the business and documented our understanding as business requirements, we need to think about:   what our software will do for the users.   Deciding what the system needs to be able to do and what it should not do, will help us to focus on producing only the necessary code.   Without a thorough understanding of the system requirements, we would risk wasting time on developing code that we’re not being paid to produce.

Instructor: Tasneem Darwish5 INTRODUCTION   System requirements are commonly separated into two categories: functional and nonfunctional.   Functional requirements are the things the system must be able to do, i.e. the services that it must provide in response to external stimuli, such as ‘browsing the catalog’ and ‘reserving a car model’.   Nonfunctional requirements are everything else that needs to be specified.   Nonfunctional requirements might include the client Web browsers that must be supported, the use of streaming video (as opposed to downloadable files) for adverts and so on.

Instructor: Tasneem Darwish6 THE BIRTH OF A SYSTEM   We may be lucky enough to get a detailed document from the customer.   Or, we may simply be presented with something like a mission statement, a short statement of some new, desirable, business direction.   As developers, we must transform the customer’s requirements document or mission statement into a complete, unambiguous description of the system to be developed, in a standard format that the customer can understand and approve.

Instructor: Tasneem Darwish7 THE BIRTH OF A SYSTEM   Admittedly, ‘complete’ and ‘unambiguous’ are impossible to achieve in practice.   However, it’s still useful to know that eventually we will have a document that describes everything the system will do with little room for misinterpretation.

Instructor: Tasneem Darwish8 THE BIRTH OF A SYSTEM

Instructor: Tasneem Darwish9 THE BIRTH OF A SYSTEM

Instructor: Tasneem Darwish10 THE BIRTH OF A SYSTEM

Instructor: Tasneem Darwish11 USE CASES   Ivar Jacobson invented use cases to define the way in which part of a business or a system is used [Jacobson et al. 92].   Although, at first sight, use cases appear more process-oriented than object-oriented, they’re widely considered to be the most effective tool for describing a system’s functional requirements.   Most nonfunctional requirements can be recorded alongside a closely-related use case (any others can be listed separately).

Instructor: Tasneem Darwish12 USE CASES   A use case starts with a participant called an actor; it then descends into the business, or the system, and eventually returns to the actor.   The effect of each use case should be of value to the actor   Of course, value can mean different things to different people: it could be some information that the actor wishes to retrieve, some effect that the actor wishes to have on the system, some money.

Instructor: Tasneem Darwish13 USE CASES   For the sake of simplicity, use cases, especially system use cases, should not overlap.   A use case is written in natural language, broken up into a sequence of steps.   Diagrams can accompany the use case for more explanation.

Instructor: Tasneem Darwish14 USE CASES

Instructor: Tasneem Darwish15 BUSINESS PERSPECTIVE   A business model can be as simple as a class diagram, showing the relationships between business entities – this is sometimes referred to as a domain model.   A domain model may be sufficient for small projects, however, for most projects, we would want to produce an entire business model representing how the business operates, or at least that part of the business that surrounds the system we expect to develop.

Instructor: Tasneem Darwish16 BUSINESS PERSPECTIVE   Use cases are not the only way of modeling a business, but they’re simple.   More complex alternatives include business process modeling and workflow analysis.   Use cases are simple because producing one doesn’t require specialist knowledge, just common sense and a certain amount of logic.

Instructor: Tasneem Darwish17 BUSINESS PERSPECTIVE   The use case model that we produce here will contain the use cases themselves plus some other pieces:   Actor list (with descriptions).   Glossary.   Use cases (with descriptions and details).   Communication diagrams.   Activity diagrams.

Instructor: Tasneem Darwish18 Identifying Business Actors   An actor is either a person playing some role within the business (as you might expect from the name), a department, or a separate software system.   The reason for identifying departments and systems as actors is that, in logical terms, they interact as if they were people themselves: we’re interested in who (or what) initiates interactions and the sequence of steps.   We don’t care whether a particular actor is ‘implemented’ as a person, a department or a piece of software.

Instructor: Tasneem Darwish19 Identifying Business Actors   Identifying actors helps us to identify the ways in which the business is used, which will, in turn, indicate what the use cases are.   Just as in real life, an actor can play different business roles at different times. For example, Fred Bloggs might be an assistant within the Nowhere Cars store until he clocks off; if he decides to rent a car before going home, he becomes a customer.   At this stage of the development, you will be working with the other sponsors (principally the customers) to find out how the business operates.

Instructor: Tasneem Darwish20 Identifying Business Actors

Instructor: Tasneem Darwish21 Identifying Business Actors