Understanding Business Processes and User Interaction Requirements

The software development process starts with the gathering of user requirements. Developing a solution based on the collected requirements helps you create applications that satisfy user needs.

Defining the Business Problem

Before writing the first line of code, you should always ask yourself why you are building the solution. The best way to understand your motives is to define a business problem that you will be addressing. The process of identifying the problem will help those affected by the project to make decisions concerning how much money, time, and resources to expend building the solution.

To find sponsors for your project, you may formalize the previous process and write a business case that describes the business need for which you are seeking a solution. Also include such factors as business benefits, expected costs, and risks. If you already have a sponsor, you should still write a business case because it provides justification for the project. Effective business cases convince management that the investment in time and resources is aligned with business strategies and is financially sound.

More Info

For more information about how to create an effective business case, refer to the Build an Airtight Business Case for New IT Investments article at http://www.microsoft.com/business/enterprise/value.mspx.

Capturing Requirements

Defining the problem is only the first step in the process of understanding business processes and user requirements. A requirement is a description of what a solution should do. Requirements can be described as either functional or operational. Functional requirements are attributes that the software solution must contain to be acceptable to stakeholders. The involvement of actual users in the process of defining and validating functional requirements is critical for the survival of the project because they provide business value to users and customers.

Experienced developers rely on domain experts as the main source of business requirements. Domain experts are people who have a clear understanding of specific areas of the business, along with its data and processes. They know how the business operates and how things are accomplished. You may find domain experts in any level of the company hierarchy, but the better experts are typically found in middle management.

Among the techniques used to capture requirements are user surveys, interviewing, and shadowing.

Writing User Surveys

Surveys are written or electronic questionnaires that users answer about what software should or should not do. Surveys help software designers to identify key issues. Some advantages of user surveys are:

They provide written evidence.
They can be used broadly and with remote users.
They are very cost efficient.

The limitations of user surveys are:

Users tend to answer ambiguously, thus making it difficult to obtain useful results. Surveys are not always effective.
They provide a broad view of the software solution, for it is both difficult and expensive to gather detailed information.
It is a limited communication mechanismyou ask, they answer. It becomes a very slow process because their answers raise new questions, thereby making it difficult to close the loop.

Surveys are a cost-efficient tool used in identifying key issues that are later detailed with interviews.

Interviewing

The most popular technique for gathering requirements is the interview. The interview is a conversation between the software designer and the user. The advantage of the interview is that it allows users to participate in a free and direct way. As a result, the designer will have a better perspective of the users needs and, if handled properly, the interview may reduce users stress and resistance to new software solutions.

Interviews bring with them two disadvantages: they are expensive in both time and resource expenditure, and they require interviewing skills. Some advice to keep in mind when interviewing customers and users includes the following:

Establish an environment of trust; the user must feel that you want to help him. When the user trusts you, he will be more inclined to help you.
Listen attentively. Take notes. The users will notice if you appear interested.
Ensure that you and the users have enough time to conduct the interview, and schedule the interview at a convenient time for both participants .
Use the interview as an observation mechanism, for the user environment is an important source of information for you.
Interview the right users. Make certain you are interviewing the domain experts who facilitate the process.
Prepare for the interview.

When interviewing users, it is important to keep in mind that the goal is to find and analyze key issues, not simply to get questions answered . You should use questions as tools to direct the conversation to the subjects of your interest. Software designers also use the interview as a mechanism to observe, identify, and capture user artifacts. Artifacts are user objects such as invoices, reports , spreadsheets, paper notes, and so forth.

Shadowing

Shadowing is a requirements-gathering technique in which you observe the user performing daily tasks in the real work environment. The advantage of using this technique is that the information is first hand and is more reliable than other sources. With shadowing, you discover the tasks that the user performs through observation and ask questions only about the reasons why the task is being performed. Shadowing is a good technique for capturing requirements on daily and repetitive tasks.

Writing Requirements

It is important that you explicitly state requirements in a formal document. Some consequences of the writing requirement process are that it helps you to better understand the requirements, find missing requirements, and preview the solution.

The formal requirements document is also an open communication channel with users and stakeholders (people affected by the project), ensuring that the project will satisfy user rather than developer requirements. Finally, formally documented requirements reduce the number of changes after the development process begins.

When capturing requirements, you should make sure they are:

Customer or user oriented
Clear and concise
Necessary and relevant
Reachable and verifiable
Complete and validated

Tip	Consider utilizing Unified Modeling Language (UML) use cases to capture and write user requirements.