Requirement and Initial Analysis

1. Requirement and Initial Analysis Imam Bukhori, S.ST

2. Starting the Development Process • This module focusses on the following: • Initiating a system development effort • Analyzing the initial workflows • Gathering information • Creating a Problem Statement • Creating Use Cases • Introducing Component and Deployment diagram

3. Gathering Information • You can gather information from several sources, including: • Customer’s initial requirement specification • Domain Experts • Customers and users • Managers • Input from marketing • Previous projects

4. Avoiding Traditional Assumptions You must avoid traditional assumptions, such as the following: • Users are naïve, developer know best • Requirements are static • You can build a correct solution the first time • Remember that projects evolve, and customer requirements can change

5. Avoiding Traditional Assumptions Do the following: • Clearly identify the user’s requirements • Ensure that your model can adapt to evolving requirements • Ensure that you can change your model

6. Domain Experts • Refers to specialist in a particular area of business • Can be broadly subdivided into: • General domain experts • Application-specific domain experts and current business domain experts • Similar business domain experts

7. Problem Statement • Is document that clearly describes the customer and system requirements for a project • Customer input is critical for this document • Uses business domain language • Has clear sentences, no jargon • Contains details on project scope • Specifies the context of the problem • Specifies any known constraints

8. Key UML Diagrams • Use Case Diagram • Shows who or what uses the system and its feature • Users of the features in a use case diagram are called “actors” • Use Case is shown as an ellipse • For ease in modeling, Use Case diagrams need to be prioritized

9. Problem Domain • Refers to a statement that clearly identifies new system-specific areas and problems • Can be graphical or textual

10. Candidate Objects and Classes • Identified from the Problem Statement • Underline noun phrases from the Problem Statement to build the list of candidate objects and classes

11. Sample Problem • The Bay View Hotel requires a computer software package to facilitate the automation of many manual tasks performed by the hotel staff. The package will be produced in several releases. • Release 1 covers the areas that are causing the most problems with the manual system. This document describes Release 1 • Problem • The hotel contains a number of hotel rooms available for hire to guest. The information relevant to each room is : • Room number • Basic price • Maximum occupancy • Type of room (single, double, twin, executive, suite) • The price of a room is the basic room price with any seasonal price adjustments added • Potential guest can reserve one or more rooms for a specific period using the telephone. These reservations are handled by the booking derks ( or departure date).

12. Simple Problem A search is made for the availability of rooms for the dates required. If successful, the customer is informed the details and price. If accepted, a provisional reservation is made. This provisional reservation is held for a duration entered by the booking clerk. The provisional reservation is modified to a firm reservation when a deposit payment is received and confirmed. This can be at the time of the initial reservation. The receptionist can also make a reservation for potential guests who arrive without a reservation, the deposit payment must be made at the time of initial reservation. It is noted when guests check in, at which time a specific room is assigned of the type required, and when the guest checks out. The room telephone is enable/disabled at checking/check out respectively. This is done using a telephone call logging monitor.

13. Candidate Object and Class

14. Data Dictionary • A document describing all the vocabulary used in a project • Entries are gathered with user interviews • Stays for the entire length of the project and the system • Adds new terminology during the project • Satisfies the need for a common vocabulary • Assists in avoiding ambiguity • Must be easily available to all project team • Needs frequent, carefully controlled updates

15. Data Dictionary base Hotel Problem • Room Number • A number that uniquely identifies a room within a hotel. The starting digit indicates the floor on which the room is located. The range is from 1 to 780 • Basic Price • The flat rate price without any additional services or special deals. • Maximum Occupancy • Each room has a specific number of guests that it can safely and comfortably accommodate • Type of Room • A room type, for example, single, double, twin, or executive. The room type depends on the size, position, furnishings, and additional facilities

16. Data Dictionary base Hotel Problem • Check In • When the guest arrives at the hotel and requests the allocation of • rooms reserved earlier. • Check Out • When the guest leaves the hotel after settling the bill. • Receptionist • A member of the hotel staff specifically responsible for checking • in/out guests and making bookings for potential guests who arrive • without an advance reservation. • Booking Clerk • A member of the hotel staff specifically responsible for taking • reservations.

17. Data Dictionary base Hotel Problem • Provisional Reservation • The logging of a request for a specific number of rooms of a specified • type, for a specified period of dates. Rooms will be held for this • reservation for a specific period. If no confirmation is obtained within • this period, the reservation will be canceled and the rooms will be • made available for reallocation.

18. Creating Use Cases • A Use Case is a graphical and schematic representation of a user’s interactions with a system • Assists in understanding system requirements and context • Graphically shown as an ellipse with solid lines

19. Creating a Use Case Model • Comprised of several Use Cases • Components are : • Actors • Use Cases • System • Generalization and association relationships

20. Sample Use Case Diagram

21. Sample Use Case add Actor

22. Sample Use Case with additional Dependency

23. Sample Use Case Diagram with New Extension Point

24. Use Case Scenarios • Use Cases show a function from the user’s perspective • A scenario refers to one instance of a Use Case • Scenarios do not contain conditional statements • Begin the same way, but can end differently • Major scenarios should be written • Successful and unsuccessful paths through a Use Case should be shown

25. Use Case Form • To Write Use Case Scenario you need Use Case Form • Item of Use Case Form : • Name of the Use Case • Actor involved • Priority • Status • Extension points and includes • Preconditions / Assumptions • Post conditions • Flow of events • Alternative paths • Performance • Frequency

26. Sample Use Case Form

27. Activity Diagram • Show activities, processes, or workflows • Are graphical • Used anywhere you need to model activities • Modeling a Use Case is just one example

28. Activity Diagrams • Includes the following elements: • Activities • Decision • Spilt of control • Merge of control • Iteration • Object flow • Swimlanes

29. Activity Diagram Notations

30. Sample Activity Diagram

31. Risk Assessment • Need to asses risk areas for the project • Use Cases can be the starting point for risk assessment • High risk Use Cases should be developed in early iterations • Risk can be in the following areas: • Requirements risk • Technology risk • Skill risk • Resources risk • Political risk

32. High-Level Package Diagram • UML has notation to package any UML elements ( classes, objects, Use Cases, incremental artifacts, and so on) • Notation similar to a folder icon • Helps break down complexity • Dependencies can be shown between packages • Packages help in doing the following: • View the big picture without too much detail • View small portions independently • Create small portions to work in sections

33. Package Diagram Example

34. Sample High Level Architectural Package

35. Introducing Component Diagrams • Show components ( physical packaging of code ) • Shows dependencies between components • Components can be nested • Can be grouped into UML packages

36. Examples of Component Diagrams

37. Another Example Component Diagram

38. Introducing Deployment Diagrams • Show physical relationships between hardware components • Can be added at any stage • Can be amended when additional information is known • Nodes can show components within them • Connection between nodes is shown along with protocol

39. Example Deployment Diagram