Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 4: Developing Requirements.

Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 4: Developing Requirements

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 2 4.1 Domain Analysis The process by which a software engineer learns about the domain to better understand the problem: The domain is the general field of business or technology in which the clients will use the software A domain expert is a person who has a deep knowledge of the domain Benefits of performing domain analysis: Faster development Better system Anticipation of extensions

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 3 Domain Analysis document A.Introduction B.Glossary C.General knowledge about the domain D.Customers and users E.The environment F.Tasks and procedures currently performed G.Competing software H.Similarities to other domains

Exercise Describe as many sources of information as you can think of that should be consulted in order to perform a domain analysis for each of the following systems Police information system — This system helps the Java Valley police officers keep track of the work they are assigned to do. Officers may be assigned to investigate particular cases, to patrol particular areas, or to attend particular events such as court cases. Some work assignments are regular ongoing assignments, while others are for a particular period of time. The system information is updated by the logistics administrator, but individual officers have an interface to display their assigned work.

Sources of information for police system domain analyis Police officers and staff Police training and procedures manuals Documentation of existing software and equipment used by police Books about police methods Similar information about related activities such as court procedures, etc.

Exercise Describe as many sources of information as you can think of that should be consulted in order to perform a domain analysis for each of the following systems Household alarm system — This software will be embedded in an alarm system controller built by Use Case Industries. In conjunction with various hardware devices, it will be able to detect and report such problems as intruders and fires.

Sources of information for household alarm system domain analyis Personnel at alarm companies, E-R dispatch organizations, and alarm equipment manufacturers Procedures manuals at these organizations Documentation and web sites about alarm hardware and existing alarm systems Experience using actual existing alarm systems Documentation about network hardware that would be connected to the system Potential end users and customers of the system

Exercise Describe as many sources of information as you can think of that should be consulted in order to perform a domain analysis for each of the following systems GPS-based Automobile Navigation System (GANA) — This system, manufactured by Use Case Industries, will be used by drivers to navigate around the state of Ootumlia. It uses Global Positioning System (GPS) technology and Internet access to a map database to provide a driver with route maps of various levels of detail, as well as spoken directions to guide the driver to his or her destination.

Sources of information for GANA system domain analyis ● Literature about existing vehicle based info systems ● Potential end-users of the system ● Auto companies in whose vehicles systems would go ● Suppliers of map databases ● Suppliers of wireless devices ● Safety studies, regulations and laws regarding usage ● Experience with competing systems ● Literature about GPS ● Psychologists and literature regarding driving skills ● Literature and experts regarding voice output ● User interface literature regarding UIs of small devices

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 11 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

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 12 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

Exercise Describe the scope of the following systems. Give some functions that would be part of a narrow scope, and some that would be part of a wider scope. Police information system

Scope for Police Information System Narrow scope: Managing basic info about areas and events to be patrolled Facilitating scheduling of duties of officers and staff Managing basic info about each case being investigated Managing documents written about each case Wider scope: Managing personnel info about officers and staff Automatically scheduling duties of officers and staff Generating statistics and trend info about crime rates, etc Managing detailed info about suspects, witnesses, etc

Exercise Describe the scope of the following systems. Give some functions that would be part of a narrow scope, and some that would be part of a wider scope. Record company web site

Scope for Record Company Web site Narrow scope: List catalog of available music for browsing Search for music by various criteria Display details about particular CDs Play samples of music Sell music on-line (ship CDs) Wider scope: Provide profiles of musicians and groups Sell music on-line electronically Allow users to make custom CDs Manage forums for fans of particular musicians or groups

Exercise Describe the scope of the following systems. Give some functions that would be part of a narrow scope, and some that would be part of a wider scope. Public library system

Scope for Public Library System Narrow scope: Searching for specific library items Browsing through lists using various criteria Checking out and returning material Adding and deleting materials from library holdings Wider scope: Handling inter-library loan Connecting to other libraries' databases Sending out overdue notices Managing fines Generating stats on items and patrons

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 19 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 have agreed that it is valid It helps solve the customer’s problem A collection of requirements is a requirements document.

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 20 4.5 Types of Requirements Functional requirements Describe what the system should do Non-functional requirements Constraints that must be adhered to during development — Quality requirements — Platform requirements — Process requirements

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 21 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

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 22 Quality requirements 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 All must be verifiable

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 24 Process requirements 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

Exercise Classify the following characteristics of an airline reservation system into functional, quality, platform, or process requirements How info about flights, passengers and bookings are entered

Exercise Classify the following characteristics of an airline reservation system into functional, quality, platform, or process requirements How info about flights, passengers and bookings are entered — Functional: input

Exercise Classify the following characteristics of an airline reservation system into functional, quality, platform, or process requirements What info appears on tickets and reports

Exercise Classify the following characteristics of an airline reservation system into functional, quality, platform, or process requirements What info appears on tickets and reports — Functional: output

Exercise Classify the following characteristics of an airline reservation system into functional, quality, platform, or process requirements How fares are calculated

Exercise Classify the following characteristics of an airline reservation system into functional, quality, platform, or process requirements How fares are calculated — Functional: Computation

Exercise Classify the following characteristics of an airline reservation system into functional, quality, platform, or process requirements What information must be stored in the database that travel agents and others access

Exercise Classify the following characteristics of an airline reservation system into functional, quality, platform, or process requirements What information must be stored in the database that travel agents and others access — Functional: Data storage

Exercise Classify the following characteristics of an airline reservation system into functional, quality, platform, or process requirements The system should be designed so that it can be extended to handle a frequent-flyer program

Exercise Classify the following characteristics of an airline reservation system into functional, quality, platform, or process requirements The system should be designed so that it can be extended to handle a frequent-flyer program — Quality: Allowance for enhancement

Exercise Classify the following characteristics of an airline reservation system into functional, quality, platform, or process requirements Only two minutes down time per week are permitted

Exercise Classify the following characteristics of an airline reservation system into functional, quality, platform, or process requirements Only two minutes down time per week are permitted — Quality: Availability

Exercise Classify the following characteristics of an airline reservation system into functional, quality, platform, or process requirements The system must run under Linux

Exercise Classify the following characteristics of an airline reservation system into functional, quality, platform, or process requirements The system must run under Linux — Platform: computing platform

Exercise Classify the following characteristics of an airline reservation system into functional, quality, platform, or process requirements A merge/sort algorithm must be used to sort flights by departure time

Exercise Classify the following characteristics of an airline reservation system into functional, quality, platform, or process requirements A merge/sort algorithm must be used to sort flights by departure time — Not a requirement!

Exercise Classify the following characteristics of an airline reservation system into functional, quality, platform, or process requirements The system will be built using NetBeans

Exercise Classify the following characteristics of an airline reservation system into functional, quality, platform, or process requirements The system will be built using NetBeans — Process: methodology used

Exercise The following non-functional requirements are stated in an unverifiable way. For each, indicate the kind of non-functional requirement that it is, and rewrite it so that it is verifiable (make up some suitable details) A modern programming language must be used

Exercise The following non-functional requirements are stated in an unverifiable way. For each, indicate the kind of non-functional requirement that it is, and rewrite it so that it is verifiable (make up some suitable details). A development process will be used that will ensure the system is of high quality

Exercise The following non-functional requirements are stated in an unverifiable way. For each, indicate the kind of non-functional requirement that it is, and rewrite it so that it is verifiable (make up some suitable details). The HTTP server will have high availability and throughput

Exercise The following non-functional requirements are stated in an unverifiable way. For each, indicate the kind of non-functional requirement that it is, and rewrite it so that it is verifiable (make up some suitable details). The system must be produced at minimum cost

Exercise The following non-functional requirements are stated in an unverifiable way. For each, indicate the kind of non-functional requirement that it is, and rewrite it so that it is verifiable (make up some suitable details). The automatic teller machine should be fast

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 48 4.6 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

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 49 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.

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 50 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.

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 51 How to describe a 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 following completion.

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 53 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.

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 55 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.

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 57 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.

Exercise For the following systems, create a list of use case descriptions A telephone answering machine

Exercise A telephone answering machine — Record outgoing message — Record incoming message — Listen to incoming messages — Skip back to previous message — Erase a message — Skip to next message — Record a conversation

Exercise For the following systems, create a list of use case descriptions The GANA navigation system

Exercise The GANA navigation system — Set destination — Start navigating — Change scale — Scroll map — Display current location — Display destination location — Navigate to destination — Change to setup mode — Obtain spoken directions

Exercise For the following systems, create a list of use case descriptions A video cassette recorder

Exercise A video cassette recorder — Play tape — Stop playing — Start recording — Stop recording — Rewind — Eject tape — Fast forward

Exercise Imagine you are developing a system to handle the functions of a mail-order company that a) manages a warehouse of goods, b) takes orders from customers by telephone, and c) ships goods overnight to customers a) List as many actors as you can think of.

Exercise Imagine you are developing a system to handle the functions of a mail-order company that a) manages a warehouse of goods, b) takes orders from customers by telephone, and c) ships goods overnight to customers a) List as many actors as you can think of. ● Shipper ● Receiver ● Warehouse supervisor ● Inventory taker ● Telephone operator ● Telephone operator supervisor

Exercise List use cases that all actors in the warehouse could perform

Exercise List use cases that all actors in the warehouse could perform Sign in Sign out Change password

Exercise List use cases that Shippers in the warehouse could perform

Exercise List use cases that Shippers in the warehouse could perform Display next order to fulfill Check off item prepared for shipment Display location of item in warehouse Complete a shipment

Exercise List use cases that Receivers in the warehouse could perform

Exercise List use cases that Receivers in the warehouse could perform Enter shipment in database Display warehouse location where item should be located

Exercise List use cases that Warehouse Supervisors could perform

Exercise List use cases that Warehouse Supervisors could perform All Shipper and Receiver functions Display statistics about warehouse performance Assign shipment to Shipper Assign delivery to Receiver Add Shipper or Receiver

Exercise Draw a use case diagram for a library system in which the actors are Borrower Librarian Checkout clerk Accounting system Show one diagram without generalization and one with generalization.

Library Use Case Diagram w/o Generalization

Library Use Case Diagram w/ Generalization

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 81 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

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 82 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

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 83 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.

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 84 4.7 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

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 85 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

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 86 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

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 87 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

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 88 4.8 Types of Requirements Document Requirements documents for large systems are normally arranged in a hierarchy Requirements Specification xxxx xxxxxxx xxx xxxxxxxxxxx xxxxx xxxxxxxxxxxxx xxxxxxx xxx xxxxxxxxxxxxxxx Requirements Definition xxxx xxxxxxx xxx xxxxxxxxxxx xxxxx xxxxxxxxxxxxx xxxxxxx xxx xxxxxxxxxxxxxxx Requirements Specification xxxx xxxxxxx xxx xxxxxxxxxxx xxxxx xxxxxxxxxxxxx xxxxxxx xxx xxxxxxxxxxxxxxx Requirements Definition xxxx xxxxxxx xxx xxxxxxxxxxx xxxxx xxxxxxxxxxxxx xxxxxxx xxx xxxxxxxxxxxxxxx Requirements Specification xxxx xxxxxxx xxx xxxxxxxxxxx xxxxx xxxxxxxxxxxxx xxxxxxx xxx xxxxxxxxxxxxxxx Two extremes: An informal outline of the requirements using a few paragraphs or simple diagrams requirements definition A long list of specifications that contain thousands of pages of intricate detail requirements specification

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 89 Level of detail required in a requirements document How much detail should be provided depends on: — The size of the system — The need to interface to other systems — The readership — The stage in requirements gathering — The level of experience with the domain and the technology — The cost that would be incurred if the requirements were faulty

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 90 4.9 Reviewing Requirements Each individual requirement should — Have benefits that outweigh the costs of development — Be important for the solution of the current problem — Be expressed using a clear and consistent notation — Be unambiguous — Be logically consistent — Lead to a system of sufficient quality — Be realistic with available resources — Be verifiable — Be uniquely identifiable — Does not over-constrain the design of the system

Exercise What's wrong with the following statement of functional requirements for a Restaurant Advisor System? This system will allow people to choose a restaurant in a city. Users enter one or more of the following criteria, and then the system searches its database for suitable restaurants: food type, price range, neighborhood, size, service type (fast food, etc.), smoking arrangements (none, etc.) The user can also specify a desired day and time period, and the number of people in the party. The system will tap into the reservation database and only display restaurants with available space. After entering the criteria, the user clicks on “Search” and the system displays a list of matching restaurants. For restaurants that participate in the reservation system, the user can click on “Reserve” next to a selection to make the reservation.

Exercise Problems with the RAS requirements: Duplication: the system searches for suitable restaurants and the system displays matching restaurants Food type, Price range, etc should be defined Ambiguity: is there an automated reservation system beyond just the reservation database? If a restaurant is not in the reservation system/database, what does the system do with it? Can user select more than one option for Food type? Can user select don't care for smoking arrangements? Omission: system should record identifying info about users who make reservations

Exercise What's wrong with the following statement of functional requirements for a simple interest calculation program? This is a handy utility for users who are considering borrowing or lending money. A window pops up when the program starts. This has three fields entitled: Principal, Annual Interest Rate, and Monthly Interest Payment. Whenever the user edits one of the fields the other two fields are automatically computed.

Exercise What's wrong with the statement of functional requirements for a simple interest calculation program? “handy” – ambiguous, unnecessary Whenever the user edits one of the fields – by clicking a button? hitting Return? entering a character? Omission: what if any of the other fields are empty? Is it simple interest or compound interest? Does the loan have a term? If so how do you indicate it?

Exercise What's wrong with the following statement of functional requirements for a Dispatcher Automation System? This system helps speed up the process of ambulance dispatching. When an emergency call is received, an automated voice recognition system classifies the case into categories depending on the level of emergency. All urgent cases are submitted to the ambulance dispatcher, who will receive the patient's record, a summary of the conversation with the operator, as well as the patient's address and medical details if known. The dispatcher uses the system to obtain the number of the closest available ambulance. The ambulance operator receives all the information about the case.

Exercise What's wrong with the statement of functional requirements for a Dispatcher Automation System? When an emergency call is received -- by who? What are the categories of emergency levels? What constitutes urgent? How is the patient's record known? (This is an emergency) Where do patient's address and medical details come from? Ambulance operator receive all the information – in what form, what medium? Automated voice recognition system: not worth the cost and not realistic

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 97 Requirements documents... The document should be: — sufficiently complete — well organized — clear — agreed to by all the stakeholders Traceability:

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 98 Requirements document... A.Problem B.Background information C.Environment and system models D.Functional Requirements E.Non-functional requirements

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 99 4.10 Managing Changing Requirements Requirements change because: Business process changes Technology changes The problem becomes better understood Requirements analysis never stops Continue to interact with the clients and users The benefits of changes must outweigh the costs. — Certain small changes (e.g. look and feel of the UI) are usually quick and easy to make at relatively little cost. — Larger-scale changes have to be carefully assessed - Forcing unexpected changes into a partially built system will probably result in a poor design and late delivery Some changes are enhancements in disguise — Avoid making the system bigger, only make it better

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements100 4.13 Difficulties and Risks in Domain and Requirements Analysis Lack of understanding of the domain or the real problem — Do domain analysis and prototyping Requirements change rapidly — Perform incremental development, build flexibility into the design, do regular reviews Attempting to do too much — Document the problem boundaries at an early stage, carefully estimate the time It may be hard to reconcile conflicting sets of requirements — Brainstorming, JAD sessions, competing prototypes It is hard to state requirements precisely — Break requirements down into simple sentences and review them carefully, look for potential ambiguity, make early prototypes

Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 4: Developing Requirements.

Similar presentations

Presentation on theme: "Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 4: Developing Requirements."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 4: Developing Requirements.

Similar presentations

Presentation on theme: "Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 4: Developing Requirements."— Presentation transcript:

Similar presentations

About project

Feedback