Introduction

There are many references and books about requirements analysis. Most, however, don't provide a reusable technique that you can apply to new problems.

The article "Creating Use Case Diagrams" comes close to meeting the reusability objective. It describes a process to transform business requirements descriptions into a set of use cases. You have to pay very close attention, though, to extract the ideas in a way that they can be applied to a new project.

This article expands the ideas in "Creating Use Case Diagrams" and casts the ideas into a pattern format, so you can easily apply it to new problems. The proposed pattern is especially helpful for developing IT systems.

Back to top

The pattern

Take the following steps to develop a pattern for business stakeholder requirements descriptions:

1. Identify the business processes.
2. Identify the IT processes that support each of the business processes.
3. Identify the activities within each of the IT processes.
4. Identify the functions within each of the activities.
5. Identify the use cases for one or more of the functions.

Using an online pizza ordering system as an example, the rest of this article walks through the steps in the pattern.

Back to top

Requirements description

A corner gourmet pizza vendor, who has operated a traditional pizza delivery service using telephone orders, wants to automate the ordering process by developing an online system. The customers need to be able to:

• Select the pizza toppings, size, and number of pizzas.
• Log in and enter the delivery address.
• Specify the time of delivery.
• Revise or delete their orders.

A store associate should be able to emulate a member login and perform the corresponding member functions on their behalf.

Back to top

Apply the pattern

This section shows what happens when you apply the pattern steps to the stakeholder requirements.

1. Identify the business processes

BP1: Order automation process

2. Identify IT processes that support each of the business processes

BP1: Order automation process

• ITP1: User management process
• ITP2: Inventory management process
• ITP3: Order management process

3. Identify the activities within each of the IT processes

BP1: Order automation process

• ITP1: User management process
  • A1: Membership activity

• ITP2: Inventory management process
  • A1: Set up pizza toppings activity
  • A2: Set up pizza sizes activity

• ITP3: Order management process
  • A1: Order activity

4. Identify the functions within each of the activities

BP1: Order automation process

• ITP1: User management process
  • A1: Membership activity

    F1: Create member
    F2: Update member
    F3: Delete member
    F4: View members
    F5: Reset password
    F6: Create store associate password

• ITP2: Inventory management process
  • A1: Set up pizza toppings activity

    F1: Add pizza topping and price
    F2: Update pizza topping
    F3: Delete pizza topping
    F4: View pizza toppings

  • A2: Set up pizza sizes activity

    F1: Add pizza size and price
    F2: Update pizza size
    F3: Delete pizza size
    F4: View pizza sizes

• ITP3: Order management process
  • A1: Order activity

    F1: Enter order
    F2: View order
    F3: Submit order
    F4: Revise order
    F5: Delete order

5. Identify the use cases for one or more of the functions

The use cases can now be identified directly using the functions in the steps above. Figure 1 shows the list of use cases. The add, update, and delete functions are grouped into one "Manage" use case. For the sake of brevity, the login use case is not shown; it's assumed to be part of the manage use case.

There you have it. All essential use cases are identified. To show how it can be easily applied to any new problem situation, let's use our pattern step-by-step to come up with a solution for the stakeholder requirements in a case study.

Back to top

Use the pattern in a case study

Look at the case study in "Creating Use Case Diagrams," and use the pattern to define stakeholder requirements for a courseware system.

1. Identify the business processes

BP1: Course automation process

BP2: Course schedule automation process

2. Identify IT processes that support each of the business processes

BP1: Course automation process

• ITP1: Manage courses

BP2: Course schedule automation process

• ITP1: Manage tutors
• ITP2: Manage course schedules

3. Identify the activities within each of the IT processes

BP1: Course automation process

• ITP1: Manage courses
  • A1: Course topics activity
  • A2: Course activity

BP2: Course schedule automation process

• ITP1: Manage tutors
  • A1: Tutor activity
  • A2: Tutor assignment activity
• ITP2: Manage course schedules
  • A1: Course scheduling activity

4. Identify the functions within each of the activities

BP1: Course automation process

• ITP1: Manage courses
  • A1: Course topic activity

    F1: Add course topic
    F2: Edit course topic
    F3: Delete course topic
    F4: View course topics
    

  • A2: Course Activity

    F1: Add course
    F2: Edit course
    F3: Delete course
    F4: View courses
    

BP2: Course schedule automation process

• ITP1: Manage tutors
  • A1: Tutor activity

    F1: Add tutor
    F2: Edit tutor
    F3: Delete tutor
    F4: View tutors
    

  • A2: Tutor assignment activity

    F1: Assign tutor to course
    F2: Edit tutor
    

• ITP2: Manage course schedules
  • A1: Course scheduling activity

    F1: Assign course hours schedule
    F2: Assign tutor to course hour
    F3: View course calendar
    

5. Identify the use cases for one or more of the functions

The use cases can now be identified directly using the functions in the previous four steps. The add, update, and delete functions are grouped into one "Manage" use case. Compare the use cases in Figure 2 with those in the article “Creating Use Case Diagrams.” Clearly, we have not missed any use cases identified. The proposed pattern has helped identify all essential use cases.

Back to top

Summary

In this article you learned about an approach to requirements analysis using a simple pattern format. Two typical example problems showed how to use the pattern. The approach and the pattern are simple to follow, and you can apply them to new problem situations.

Resources

Learn

• "Creating Use Case Diagrams " (developer.com) by Chitnis, Tiware, and Ananthamurthy provides a technique for identifying use cases.
  
  
• "UML Tools" (developer.com) by Chitnis, Tiware, and Ananthamurthy is a courseware case study that discusses features of UML tools.
  
  
• New to Architecture on developerWorks has an excellent collection of articles and references on requirements analysis.
  
  
• In the Architecture area on developerWorks, get the resources you need to advance your skills in the architecture arena.
  
  
• Stay current with developerWorks technical events and webcasts.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

Get products and technologies

• Download IBM product evaluation versions and get your hands on application development tools and middleware products from IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  

Discuss

• Participate in the IT architecture forum to exchange tips and techniques and to share other related information about the broad topic of IT architecture.
  
  
• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the author

Nalla Senthilnathan has worked as an IT consultant designing and developing enterprise Web applications for the past seven years. Nalla holds a Ph.D. in mechanical engineering from the National University of Singapore.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• The pattern
• Requirements description
• Apply the pattern
• Use the pattern in a case study
• Summary
• Resources
• About the author
• Comments