Chapter 5 - Requirements Analysis

Introduction to requirements analysis

Often, the act of analysis is a no man’s land, lost between requirements and design. Many are unsure where gathering requirements ends and analysis begins, and also where analysis ends and design begins. This confusion has occurred because of our natural delineation of time and actions into comfortable compartments. All three of these processes revolve around one another. Rather than try to delineate the separate actions, it is better to consider the work products. Production of the documents and models then helps to put time and action into logical compartments.

Another confusion is the overuse of the term analysis. Many analytical techniques are required in the creation of software. Foremost among them is domain analysis, and the most prevalent domain is business, where a business analyst gathers requirements by analyzing the business. Other domains requiring analysis are electronic or robotic systems, or areas of science or health.

Martin Fowler's Analysis Patterns[1] discusses domain analysis. He looks at observation and measurement (primarily in the health service), inventory, accounting and trading. In such large and complex environments a lot of analysis is required before, during and after gathering requirements.

Another broadly used term is systems analysis, from the structured systems analysis and design method (SSADM). Systems analysis is a conglomeration of analytical methods. Feasibility analysis, cost/benefit and risk analyses, and objective and constraint analyses may be required along with hardware analysis to determine machine build specification.

If you are building a newer version of an existing product, you will have to analyze the previous version. If it shares libraries with other products, you may have to carry out reuse analysis and impact analysis to discover what might happen if you break another application.

All of the ways the word analysis is understood makes it important to identify the type of analysis being undertaken and clearly communicate the scope of analysis.

Requirements analysis gives us:

  1. Requests for more domain analysis

  2. A decision on whether we need a new project or activity to look at cost, benefit or feasibility

  3. Additional requirements, deleted requirements, clearer requirements

  4. A foundation for our design comprising actors, use cases and process flows

Requirements analysis will be considered using three examples of potential software systems. Two are straightforward, one a clock and the other an ATM. The third is slightly more complex, and is a sales order processing system.

Requirements Analysis

When requirements seem almost gathered. When user workshops are beginning to uncover less. When the phoning, cajoling and confusion over what the product will do are reducing. When scenarios are written, and when the frequency and timing of the actions represented by the requirements are identified, analysis will become the dominant task. During analysis you are testing the requirements to see that they are complete, that you fully understand them, that they are possible, and that you have enough information from which to create a software design.

This work will take place during and between the user workshops. The reason it is separated from gathering requirements is to clarify the separate goals of gathering and analyzing. However, separate goals do not always mean separate activities. I would go as far as to say that until you have analyzed the requirements, they are not fully gathered.

During the analysis phase, at the project level, you will:

At the architectural level, you will:

Use Cases

Use cases were presented in the section on modelling. To better understand what a use case is, let’s identify the rather well worn use cases of an ATM, or hole in the wall money machine.

When identifying use cases, simply write down a high level list of all the things that the system does, or will do. In the case of the ATM, depending on its complexity, you may be able to withdraw money, pay in a cheque or cash to your account, or view your account's balance.

Here is the Use Case diagram for the ATM.

Figure 5.1 ATM Use Case diagram

The ATM is shown in an enclosed square as a set of use cases. The ATM customer is external to the ATM, so is shown outside the box.

Use case models can be very useful in reverse engineering existing applications as well as modelling new ones. The use case model of an application is probably the highest level of abstraction you will use. It briefly states what the application does and for whom it does it.

It must be easily understood. If you end up identifying a hundred use cases, either your system should be broken down into a number of smaller projects, or you are modelling use case pathways rather than use cases. If you end up with one use case, then you need to move down a level of abstraction or get a bigger project.

Mapping Use Cases to Requirements

Once you have a use case diagram, you can then map use cases to requirements. If possible, testers can be brought in at this point to begin to get a feel for the product, and to run this first test.

Figure 5.2 Use case to requirement mapping

Some requirements will belong to no specific use case, but will apply to all of them. These are requirements for response speed, or user interface look and feel. In some cases, it is advantageous to create a separate use case for unmatched requirements. In other cases, the requirement may apply to one or more of the use cases you have already identified. In the example of figure 5.2, you may find a loose requirement for security, and yet another for look and feel. You decide to add a security use case for the security requirement, and apply the look and feel requirement to all use cases which have user interfaces.

Figure 5.3 Use case and requirement relationships showing look and feel and system security

The following use case diagram shows how a security use case might be shown in a use case diagram. Notice that the requirement for look and feel has no mention in the use case model. This shows why the above type of grid is useful to test for complete coverage of requirements by the use cases. 

 

Figure 5.4 A use case diagram modelling security

Modelling security in a separate use case does not imply it will be implemented separately. All use cases could have been shown as «inherits» security, implying an implementation of security as a base class. Some modellers claim such decoration in a use case diagram is unnecessary. Analysis is only the beginning of a process in which you understand and design your killer software. Analysis models are often thrown away, as the analysis is more a voyage of experimentation and discovery. Implementation details are defined in the design stage.

Detailing Use Cases

Consider the following narrative:

‘Harry always fetches a battery when the current one has run down. He can’t put it in though, that’s Sally’s job. Sally sets the hands too. Unfortunately, she has a bit of a problem with which number the hands are pointing at, so Harry always has to do the reading. He’s just told us it’s half past two. I can read the clock, but as he always announces it, I don’t need to.’

You have been called in as a Software Architect, and you are alone. The sponsor is the leader of a department comprising the above people. He is tired of the constant time calling out towards home time, as that is when he is most busy. He wants some software to solve his time-calling problem.

To begin the analysis, the conversation is broken down into subject, verb and object tasks. In doing so, it is important to identify the role rather than the person, assuming that the operation would carry on if one person left the team and was replaced by another equally skilled soul.

Subject Verb Object Frequency Occurrence pattern Result
1 Battery fetcher Fetch Battery 4 times a year Periodic A new battery is procured
2 Battery fitter Fit Battery As above As above New battery is fitted
3 Hand setter Set Time Once a week Periodic Time is correct
4 Time reader Read Time Ten times a day Aperiodic, exponential increase near home time Time is known to Time reader
5 Time announcer Announce Time As 4 As 4 Everyone knows the time

In summary, the battery needs fetching and fitting, and the time needs setting, reading and announcing.

We have two objects, time and battery. We have five user roles of battery fetcher, battery fitter, time setter, time reader and time announcer. Although Harry fetches the battery, reads and announces the time, these are separate roles, and should not be combined into one just because they are done by the same person. At implementation time, we may have a time announcer ability, a time reader ability and a battery fetcher ability, all of which Harry, the person, can do.

We also know how often these activities happen, the pattern of occurrence, and the result of the activity. That is quite a lot of useful information about the system.

From this, we can identify and number the use cases of the current system. At first glance, we might try this...

  1. Procure battery
  2. Insert battery
  3. Adjust time
  4. Read time
  5. Distribute time

...only to realize read time and distribute time are hardly separate use cases, but separate activities in the same use case. It is also unlikely the battery will be part of the software system. Once this is identified, its continued discussion will be fruitless. Thus, we end up with a choice of having a use case with read and distribute time, and another use case of adjust time, or a single use case containing all three.

  1. Adjust time
  2. Read and distribute time

or

  1. Use clock

Figure 5.5 the activities of time

Maybe there are prerequisites and post-requisites for these use cases. For example, as this is a work clock, the employees should all have arrived at work before the time machine can function. Knowing the time requires some sophisticated teamwork. If one member of the team is missing, there will be no time, so they won’t know when to go home. Maybe your software will need to take this into account.

Each use case should be given a brief description. In the case of the ATM, you may write something like this:

All of the following use cases require the ATM customer to insert their card and enter their PIN (Personal Identification Number) before proceeding.

Use case 1. Withdraw money

The ATM user specifies the amount of cash and receives their money.

Use case 2. Get account balance.

The ATM user requests and receives their account balance

Use Case 3. Post cash or cheque

The ATM user takes an envelope, puts in their cheque or cash, and posts it into a secure receiver.

Following, or during each use case, the card is returned to the user at an opportune moment.

While the example of an ATM might not strain you too much, I am sure the use cases you define for your business or system will be more difficult.

You may decide to present use cases in a shell much as you did with requirements. It depends on the complexity of the system. Here is a more complex use case presented in a shell:

Use Case Number1
Title The system allows the user to search for goods in stock
ActorsSalesperson, stock controller, warehouse picker
PreconditionsThe inventory of the warehouse is held in the system and is maintained up to date
DescriptionThe use case starts when the user enters the ‘search for goods in stock’ screen. The user enters a product code, supplier or partial description, then the system does an appropriate search, displaying the results of the search in a list. The user then selects from the list, and the details of the selection are displayed. Only one item may be displayed in detail at once, and the user may return to the list or where they were when they initiated the search
Alternative flowIf no stocked item matches the search, then the user may request a search of goods from their suppliers. See use case 3
ExceptionsIf the system fails at any time during the search, then the user must know why. Reasons for failure may be licensing issues, known or unknown exceptions such as system crashes, data locks etc.
AssumptionsThe users are aware of the terms used in their stock system. See glossary.
Post conditionsAs this use case cannot edit data, nor order stock, the only post condition is that the user is returned to the screen from which they initiated the search.
User interface{rough picture}
Business rulesOnly the above mentioned actors will have access to this system. When showing product details, cost prices must be omitted for salespeople.
Associations
Constraints
Risks
Issues
I: Before this use case is implemented, we need another user workshop to agree the information titles
Reference1, 2
Revision log
Modified by Date Version Description
IB Curley 01.01.22 0.1 Draft

The shell can be useful to ensure information is not misplaced when it may be required later in the project.

The primary, secondary and exception use case pathways

Each use case will have a number of possible courses of action through it. Each course of action is documented separately, and identified as a primary, secondary or exception path through the use case. Depending on the complexity of these paths, they may be modelled separately or together.

The primary path

This is the most obvious, and most often travelled path through the use case. It is referred to as the happy path. For example, in our sales order system it might be:

  1. Customer telephones salesperson
  2. Customer and/or salesperson identify account
  3. Customer identifies whom the order is for
  4. Customer lists all required items
  5. Customer states payment method
  6. Salesperson confirms order

Secondary paths

There may be no secondary paths for your use case, although this is unlikely. Here are some secondary paths for the order processing use case.

  1. Customer telephones salesperson
  2. Customer and/or salesperson identifies account
  3. Customer selects a ‘quick’ code from a series of pre-defined order templates
  4. Salesperson confirms order
  1. Order is emailed in
  2. Salesperson identifies account
  3. Salesperson enters order items
  4. Salesperson emails customer to confirm order

There may be a great many of them, and it may take some effort to document them all. Not documenting them is a sure way of delivering software that doesn’t meet the recipients’ expectations and fails to help them do their job.

Exception paths

Usually considered last are the exception paths. This does not mean they are any less important than the primary or secondary paths. Here you model error traps, or unexpected exits from primary or secondary paths.

  1. Customer telephones salesperson
  2. Customer/Salesperson identify customer’s account
  3. Salesperson enters order items
  4. The call is interrupted
  5. The salesperson saves the order as a non-completed order
  1. User enters invoicing
  2. User begins invoice run
  3. System crashes
  4. System is rebooted
  5. User rolls back previous attempt at invoicing, and begins again

Presenting the paths

Use case pathways can be presented in a numbered sequence as shown above, or by using activity diagrams. Figure 5.6 shows an activity diagram for a typical sales order processing system.

Figure 5.6 Order processing activity diagrams - primary path(left) and all paths(right)

Using Scenarios to detail and agree use case pathways

Use cases and requirements on their own can leave a few gaps in the transfer of knowledge between customer and developer. The most convenient way of plugging these gaps is to use scenarios.

An example of a scenario is this:

Scenario 1. Use Case 1. Withdraw money
Related Requirements 1, 2

An ATM user enters their banker’s card in the card slot. The machine reads their identity from it, and links to the bank’s main system. The user then enters their PIN number - a 4 digit numeric code - which is verified by the bank’s system, selects an amount of cash from a menu (e.g. £50) and selects to have a receipt printed. The customer then receives back their card, their cash and a receipt, in that order, and leaves the ATM.

Scenarios in this form are better from the customer’s point of view as narration is more familiar to them, and easier to agree with, or change.

Whether you are using use case pathways, scenarios, activity diagrams or a mixture of all three, you must fully detail all use cases and how they fulfill the requirements. Enough information must be included for the user group to fully qualify them, and for the designers and developers to be able to implement them.

Actors

We have already defined the actors in the clock system as the battery procurer, battery fitter, time adjuster, time reader and time announcer. As already stated, the battery requirements are not applicable, so you are left with three actors:

Actor 1. Time reader
Actor 2. Time adjuster
Actor 3. Time announcer

Remember the sponsor who is paying for this work. He is not an actor, but he is certainly a stakeholder. He wants actor 3 removed from the process. He wants a single time adjuster so they won’t argue over what the correct time is, and a number of time readers, all reading their own time. He doesn’t want use case 3, time announcer, to ever happen again.

Therefore, the system will have two actors. That’s what you are being paid for:

Actor 1. Time adjuster
Actor 2. Time reader

Here are the two actors shown with two use cases of read and adjust time.

Figure 5.7 Use case for a clock

One of the actors for the ATM is slightly less obvious than the other.

ATM Actor 1: ATM Customer
ATM Actor 2: Bank’s main system

Both of these are actors as they are external to the ATM. An actor doesn’t necessarily mean a person. It can be an object too.

The sales order processing system will have only one actor. The sales order clerk takes the order from the customer and enters it into the system. There is no direct link between the customer and the system.

Sales Order System Actor 1: Sales order clerk

System classes, objects and relationships

Let’s work on our time delivery software. During the interval between two user group meetings, you throw together a few ideas for the visuals from which they will read the time. You already know that they are most interested in time toward the end of the day, and how the countdown to home time has the utmost importance

Figure 5.8 Time and countdown displays

You present your user group with your ideas, and explain how time can be displayed graphically as a clock, or graphically as a shrinking segment showing the remaining work time disappearing. Shrinking time can also be shown as a bar, or finally, the time can be displayed digitally.

Of course, they look at you as if you are mad. All they ever wanted all along was a digital clock, but their boss would never buy them one. Neither was there any way for them to suggest to him that they wanted one as when they remembered it, he had his door locked. He always did this in the later part of the day so he could get some work done.

Being a conscientious Software Architect, you bill your customer for the few hours you have spent with his team, buy them a digital clock out of the proceeds, and explain to your customer how he can get hold of you again when his next software need crops up. If you do not know why you would follow this course of action when you could easily develop a digital clock and charge a king’s ransom, it will be discussed later.

So much for the clock. Let’s look inside the ATM; it has cogs and things. It may be fairly simple from the point of view of how it is used, but behind that innocuous small screen lurks a world of software control.

Consider what happens.

A user walks up to the machine and inserts a card. The card is drawn in without the user offering too much assistance, so there is a sensor to recognize when a card has been inserted, and a means of pulling in the card at a constant speed while the magnetic strip is read. There is also a sensor to signal when the card is fully inserted. The motor drawing in the card must stop otherwise it will overheat, wear out and possibly damage the card. When the card is ready, the smart card chip is read and verified. At this point, the screen changes, requesting the ATM user’s PIN.

Software records the button presses, and when it has a complete PIN, verifies it against the bank system. In  the meantime, the user is informed of a potential wait while the bank system responds. Following a positive response, the ATM user can now demand money. More user interface work is followed by counting out the money. Sensors, actuators and software combine to count out the money. There’s no room for error here. Should it be counted twice for verification? How would you design it?

Figure 5.9 Analysis of the classes in the ATM

The counted money is sent for collection, but first the card is fed back out of the slot. Your card must be removed before the cash door opened. A cunning safety feature. How many times have you stood there waiting for the cash while your card is waiting for you? You take your card, take your money, and the screen informs you your receipt will be with you shortly. More software, more hardware controlling a dot matrix printer. More software, more hardware feeds the receipt out of the slot. After a pre-determined time, even if you have forgotten your ticket, the machine becomes ready for the next customer.

That’s a lot of software required. Figure 5.9 shows an analysis model of the  ATM from the point of view of someone other than the user. It shows all of the control, interface and entity classes of the ATM which have been discovered so far, and uses UML’s package notation to group objects within the card reader and the cash dispenser.

System objects

Perhaps at this point it is necessary to detail system objects, which are created from the system classes. In the aborted clock application, while it was still going to be a bit of software, you might have had a single class of timeRecipient, i.e. one who heard the time announcer, yet multiple objects would be created from that class.

Similarly with the ATM. Maybe it is a new design supporting a row of five users, five card slots and screens, yet only a single money counter, and an additional class of money router to make sure the correct recipient received the correct bundle of money. Why are ATMs always designed as stand alone machines, helping one user each at a time?

While pondering that, ponder over other products too. Do you put as much effort into your software products as product designers and engineers do into theirs?

The road to Moscow, the triage, the traffic lights, eighty-twenty and the low hanging fruit

It is no accident of nature that few ripe cherries hang under the lower branches of cherry trees. They are picked and eaten because they are the easiest to get to. They are the low hanging fruit.

Some requirements provide a huge benefit to the users and are easy to deliver. They are the low hanging fruit of the software development world, and should be plucked first in any project.

If the cherry tree is mature and large, a picker may be able to gather 80% of the cherries by standing in a few places and reaching out. The outlying cherries at the ends of branches or in awkward and dangerous to get to places, are hardly worth picking. Specialist equipment such as ladders and carefully prepared ground may be required, and more agile pickers. Compared to the 80% which were easy to pick, the final 20% take a huge amount of effort for their relatively small return. As a rule 80% of the cherries take only 20% of the total picking effort; and is known as the 80/20 rule. It is also referred to as the law of diminishing returns as each successive batch of cherries picked takes more and more effort.

In software terms, a project should deliver 80% of the benefits for 20% of the effort. It may even be worth moving on to the next project and reaping 80% of those benefits before delivering any more on the current project.

Once upon a time on a battlefield, triages were performed to filter out which wounded might be helped most expediently. Triages are still used in disasters and emergency situations when medical resources are limited. In a triage, four classes of people are identified: the dead, immediate, delayed and minor. The dead are left where they fell. Thos with immediate needs are seen to first. The delayed are aided once all of those with immediate needs have been processed. Finally the minor, or the walking wounded, are given aid.

The three classes of immediate delayed and minor are comparable to requirements. Some need doing straight away, others can wait, and yet others are only minor requests. Putting this into the traffic light metaphor of green for immediate, amber for delayed and red for minor will provide a hypnotic suggestion to go on the immediate, wait for the delayed and to stop worrying about the minor problems.

Combining the three divisions with the requirements' Must have, Should have, Could have, Would like (MoSCoW) ratings and the difficulty of doing them, will provide a beneficial and more comfortably defined road along which to travel.

Technological options

When listing technological options, don’t be too eager to display your vast knowledge. If the client already has a platform in use, you should do your best to use it.

For example.

Widget X or Y, which is already in use, could be used for doing Z.

Our platform is either server cluster Everest or K2.

The application should fit in with the previous three we have developed for this customer, and share as many components as possible, including the framework.

No decisions are made at this point whether X or Y is better. They are choices made during design.

If some of these choices are going to be difficult, some discussion of their merits would be wise this early on, so those outside the technical team can understand the choices to be made.

Navigation

Most projects will involve some navigation. To enhance the user experience (remember those words) you should identify how the roles traverse the software system, and also how the people fit into the roles. You may find someone on the sales desk is also responsible for managing purchase ordering. In this case, it would be helpful for them to be able to navigate to the purchase ordering function from within the sales order function.

If you consider how we, as humans, interact with each other, we use our interfaces. We call them senses: sight, hearing, touch, taste and smell. We also use our experience, our knowledge of each other, our joint experiences, our compassion, empathy etc. We have little need for navigation around those interfaces. It happens all at once, we use them all together, all the time.

The concept of navigation can be compared to altering our frame of reference. We may pick up a paper based ledger and think of it in terms of accounting, then put it aside and pick up the telephone to make a purchase order. Our frames of reference are in our minds. If we can capture that flow and present it on a screen, then our user will be more content with the flow of the system. Navigation means detailing how users see the system, and how it helps them move between different frames of reference.

Navigating items represented on a computer screen is limited to point, click and type at present, and to a limited extent, speech. One day you may be able to smell an overdue document or hear a problem coming. One day turning your head a little will allow you to change your point of view.

Deliverables

At this point, the deliverables may be no better defined than at project initiation. If they are taking shape, a best guess at a deployment model is in order. A simple UML deployment diagram is quite sufficient, or if you must choose between alternatives, then a diagram of each of the alternatives, annotated with risks and benefits, will help others understand the choice that will be made.

Breaking down large pieces of work into a number of interdependent projects.

Suppose a project has been defined to deliver a vehicle insurance claims system. The main high-level activities are as follows:

Figure 5.10 Work breakdown of vehicle insurance claim showing dependencies

Early treatment of injuries by physiotherapy has been shown to significantly reduce the number of sessions required. Similarly, careful early management of a claim can lead to resolution between the insured and the insurer, and thus avoid the additional costs once a solicitor becomes involved. These two items will provide greater cost savings than the rest of the activities combined.

Diagram X shows how the initial case management is dependent upon the set up claim activity. Setting up the claim is dependent upon Allocating the work to someone. However, there is a possibility that this can be a manual process carried out by the team leaders in the initial project stages.

The decision of what to do is a balance of three forces:

  1. What delivers some measurable benefit?
  2. What are we capable of doing?
  3. How much will it cost?

These three forces can multiply into a multi-dimensional decision, based on further environmental conditions. As an example, the above three forces could become ten dimensions in a project or programme, considering:

  1. What are the benefits?
  2. What are the estimated costs?
  3. What can we reuse?
  4. How will it fit with our rhythmic delivery cycle of four releases a year?
  5. What business process re-engineering is required?
  6. What are we collectively (people and tools) capable of?
  7. How do we deliver iteratively, focusing on benefits?
  8. How do we do integrate with legacy systems?
  9. What legacy systems do we link to?
  10. How do we minimize the pain will we cause our handlers during an iterative rollout?

All of these dimensions affect how the decision is made of what to do.

The initial work is rather obvious, and must focus on managing the initial contact. To do so, setting up claims must also be included. The second phase of work will have little benefit, but will lay the ground for the rest of the work, and will be work allocation.

If the benefits of the remaining work can be calculated, deliver the highest benefit first. If not, pick any. The last deliveries will be vehicle replacements, vehicle repair and investigator assignments. Recovering money is likely to be closer to the heart of those pulling the strings, and recoveries has a dependency chain before it, all of which must be delivered beforehand.

The project will cost 130k, and at the end of the work will deliver 26.6k benefit per month. Adding in operating costs of 5k per month, the break even point will be in September.

Figure 5.11 High level programme plan against costs and benefits

List of terms and data dictionary

For our clock, should the project have gone ahead, we may have identified:

Time - that elusive snatcher of our lives. The wave on which we travel and cannot control.

Hour, minute and second – increasingly detailed divisions of time.

Home time – the hour at which we are released from our work obligations.

Lock – the thing the boss uses in his door when he wants quiet.

For a sales order processing, accounting and management system, we might have a data dictionary defining every field discovered, and the characteristics of each item.

Item Description Object property name Data name Type Size Accuracy
Employee Someone who works for the company .employee EMPLOYEE_NAME String Variable up to 50 characters N/A
Salary The annual or hourly wage paid to the employee .salaryYear
.salaryHour
SALARY (held by year only) Money 999,999,999.99 2 decimal places
Date of Birth Date an employee was born .dateOfBirth DATE_OF_BIRTH Date N/A To one day
Age Number of years since Employee’s birth .age Derived from DATE_OF_BIRTH Integer 16 bit To one year

During analysis, this can become fleshed out by adding more detailed information. For example, you might define a person as having a grade. The grades the company uses are listed, as are the various terms they use for their clients, assignments, etc. This list of data alone is referred to as a taxonomy. Taking it a step further and defining relationships between the various pieces of information makes it into an ontology.

User group review

When the information gathered and formalized is sufficient enough, it is presented for user review. In the final stages of requirements analysis, the entire team agrees differences, completes outstanding work, and gets a feel of where their efforts are headed.

The final analysis

The findings of analysis will feed back to requirements, and back to the project plan. After analysis, you may decide that the project is actually a programme of work and must be broken down into a series of projects. In the case of the ATM, we had a package for the card reader, and one for the cash dispenser. Both communicated with the rest of the machine via the master controller. In this case, we could define the master controller, then spin off three separate (although interdependent) projects to deliver the system. 

It is in cases such as this where a Software Architect can flourish, by laying the foundation and rules on how the component projects will work, and how they will communicate with each other.

Summary

A process has been followed whereby use cases are identified and drilled into using use case pathways and activity diagrams. Event frequencies and periodicities have been ascertained, and supporting data identified. This approach is referred to as use case led software development.

The activities of analysis are those of understanding and documenting. How to reach understanding is the subject of [3]. 

References

  1. Analysis Patterns. Martin Fowler. Addison Wesley.
  2. The Unified Software Development Process. Ivar Jacobsen, Grady Booch and James Rumbaugh. Addison Wesley
  3. Problem Frames: Analyzing and structuring software development problems. Michael Jackson. Addison Wesley.

Questions

  1. Redraw the ATM showing its two use cases of customer and bank's main system
  2. Identify the use cases of a website where you can order books.
  3. Write down the primary, secondary and exception pathways of an ATM, and draw a single activity diagram containing all of the pathways.
  4. A simple word processor can load, edit and save files. How many use cases does it have?
  5. An application requires 4 developers at a cost of 5k each per month, and will save the company 20k per month once it is complete. The development estimate is 4 months, test one month and deployment phased in 10 equal steps over the next month. After the start of development, when is the break even point for the project?
Click here for the US book list
Click here for the UK book list