1 Feb 2016

Creating Your Software Requirements

Creating Your Software Requirements

Author: Jill Embry  /  Categories: Project Management, General Client Topics  /  Rate this article:
5.0

 

Part 1: Defining Actors and Use Cases

When deciding to have a custom software application developed, there are several things needed that do not fall under the responsibility of the developers themselves. One of the most critical components is the Requirements Document. And it is your responsibility to create it. After all, the developers cannot see inside your head, yet. They do not know how your company functions, who does what and what you are trying to achieve. At some point during the development process, with enough communication, they will be able to anticipate your desires, but they need a starting point.

 The Requirements Document has many components. It, in general, describes what your application “Should do” and “Shouldn’t do”. It defines the system, functional requirements, and user requirements along with several other aspects of the application. In another article, we address what should be covered in a complete Requirements Document. Two key components are the actors and the use cases. Actors are those individuals or systems that will interact with the application. Use cases are series of steps or related interactions that are performed by an “Actor” on the system in order to complete a goal.

Naming actors is not the first step you should take in deciding what your application should do, but it is definitely second or third. The first step is deciding what is the problem you are trying to solve with your application. Without that as the foundation, anything else is irrelevant.

Actors

Defining actors seems like an easy task. Who will use the system everyday? But many people just look at this from their perspective of who do I interact with through the system. So, for instance, if you are designing a banking application for online banking, you may think of just the perspective of the “bank” and the “bank customer” as the two actors. Yet there are several others that interact with the system from not just a software perspective, but also from an external software and hardware perspective. In addition, these actors should be broken down into two categories, primary and secondary. The primary actor is the actor that is directly interacting with the system to achieve a goal. The secondary actor is the actor is external to the system, but is called upon to help complete a goal. For instance, the secondary actor may be a printer needed to print an invoice or a CEO that may get reports delivered to him, but takes no action in the application.

Examples of actors

Primary

Administrator: Assigning roles in the system, creating account permissions, updating software

Project Manager: Schedule projects, define requirements, check project status, generate reports

Customer: search products, purchase products, create wish list, create profile

Secondary

Microsoft Outlook: Meeting schedules are exported to outlook

Picker in Warehouse: Orders are printed and received by picker

Database Server: provides or stores data

For each of the examples above, their interaction with the systems can change with each use case. A picker in the warehouse can become a primary actor if he is required to interact with the system to achieve a goal. So if he needs to be able to create a shipping label for orders picked, he then becomes a primary actor in that use case. Because of this, documenting the use case with the actor becomes key, since their role can change. Therefore, a single individual can be presented as multiple actors.

 Use Cases

If you understand the actor’s roles, the use cases are not difficult to come up with. The challenge is making sure all the steps in an interaction are covered. The goal is not to consider the user interface or user interaction at this stage, but rather document what needs to happen to complete the goal of the use case by a particular actor.

The number of use cases associated with a single actor can be a single one or multiple. They may be simple or complex. The expectation is not for you, as the client, to come up with every step in the use case. It is to provide enough information to help the rest of the team assist in creating thorough use cases. Also, keep in mind, the use case to reach a particular goal for one actor may be different for the same goal for another actor. So, when creating use cases, the actor must be front and center in your mind.

When sitting down to write your use cases, keep in mind, there are several ways to do so. It is important to pick the way you are most comfortable with. Since your goal is to convey to the development team what the application needs to do, the mode of communication that you are best able to convey this should be the one to use.

 If it is easiest for you to provide a narrative, which is a paragraph text description of the use case, you will need to include the pertinent information for the actor to complete their goal. These are, the intent of the user in performing the use case, the active steps that are needed to obtain the goal, and key outcomes of the steps that are needed to reach the goal.

If you prefer to write the use case as a scenario, you will need to identify the actor and the intent as an introduction. After that, all you will do is provide a step by step list of actions and responses of the actor and the system. This is a lateral description, without side interactions. So the scenario approach is a high level description with the key components listed out in a stepwise manner.

A third way that use cases can be written is through use of a Unified Modeling Language (UML) Use Case Diagram. These can be very simple diagrams to very complex. They can contain one actor with many use cases or to simplify, one actor and one use case. This is my favorite form for use case presentation if having to select, since it shows an easy to follow visual of how the actor interacts with the system and how the system responds. Combining the scenario format and the diagram format in the specification gives a clear understanding of what components, interactions and responses are in the use case.

 Examples of Use Cases

Actor: Customer on Online Commerce site

Secondary Actor: Email system

Goal: create an account

Narrative: The customer on an online shoe store would like to create a new account. They must first provide their personal information in terms of name, shipping address, billing address, primary phone number with the ability to select the type of phone number it is, email address, username and password. These are all required fields. In addition, they may add a primary method of payment, which must be secure. The payment method should be able to be used to make quick payments. The password needs to be able to be reset by the customer via security answers once a validation email is sent. Before using the account, the customer must activate it via an activation email.

Scenario:

Actor: Customer on Online Commerce site

Secondary Actor: Email system

Goal: create an account

Customer opens online store home page

Customer clicks on Create an account hyperlink

Customer enters registration information

First Name (Required)

Last Name (Required)

Shipping Address (Required)

Billing Address (Required)

Primary Phone Number (Required)

Type of Phone Number (Required)

Work

Home

Cellular

Other

Alternative Phone Number

Type of Phone Number

Work

Home

Cellular

Other

Email (Required)

User Name (Required)

Password (Required)

Password Confirmation (Required)

Payment Method (Required)

Credit Card Number (Required)

CVC (Required)

Expiration Number (Required)

Security Question Selection (Required)

Security Question Answer (Required)

Customer clicks to activate the account

System checks for duplication in name, email and phone number

System checks for validity of phone number, email, credit card information

System sends an email to email address of customer entered with activation link

Email system of customer receives the email

Customer clicks on link to activate

System creates a profile and activates the account

System opens browser page with confirmation of activation and option to go to login page

 

UML Use Case Diagram:

 Actor: Customer on Online Commerce site

Secondary Actor: Email system

Goal: create an account

 

Summary

Although there is much more detail needed in creating your design specification, providing clear use cases for each of your actors is critical to ensuring your team designs the application you need for your business. Since you are a team, everyone involved should contribute to the activity of defining the actors and use cases. In addition, the actors within your organization should also help define their individual use cases, keeping in mind that any individual could serve as multiple actors.

The best software systems are developed when the actual actors of the system are involved early on in the design phase of the project. This not only ensures that critical process steps aren’t missed but also enlists buy-in from the future users. So often software systems are built without consulting the users. And when presented with the final system they hate it because it doesn’t fit the way they work and worse, doesn’t give them the information they need to do their job. This can all be avoided by getting them involved early and often during the software development life-cycle.

Print

Number of views (2207)      Comments (0)

Jill Embry Jill Embry

Other posts by Jill Embry

Leave a comment

Name:
Email:
Comment:
CAPTCHA image
Enter the code shown above in the box below
Add comment

Subscribe to our mailing list

* indicates required



100% VETERAN OWNED BUSINESS
.NET DeveloperYou can count on us to get the job done. As the Army ad says "We get more done before 9am than most people do all day." READ MORE

Search All Blog Entries

«February 2017»
MonTueWedThuFriSatSun
303112345
6789101112
13141516171819
20212223242526
272812345
6789101112

CASE STUDIES

Learn about the patient management system we developed for Dartmouth-Hitchcock Medical Center and other case studies.

READ MORE

TESTIMONIALS


See what clients are saying about Keene Systems.              READ MORE

Successful companies choose the best consultants again and again. Keene Systems developed software for some of the world's most prestigious companies.

FULL CLIENT LIST

FREE GUIDE


HOW TO PLAN A SOFTWARE PROJECT

SQL server developer | SQL Server consultant

Whether you're starting a new business, upgrading a process or revamping your business as a whole, software project planning is essential for your success.
                DOWNLOAD