Written Assignment - Writing Requirements Consider a project to install an electronic system that will control the dispensation and packing of drugs in a pharmacy. Prepare at least eight requirements

Week 3-Written Assignment, Rubric, & Lesson Content

Written Assignment - Writing Requirements

Consider a project to install an electronic system that will control the dispensation and packing of drugs in a pharmacy. Prepare at least eight requirements that the pharmacy may have for this project. Be sure to include business, user, and technical requirements.

Submit your completed assignment by following the directions linked below. Please check the Course Calendar for specific due dates.

Save your assignment as a Microsoft Word document.

Rubric

Module 03 Written Assignment - Writing Requirements

Lesson Content

Requirements Gathering

What Is a Requirement?

A requirement is a description of what the product or service being created must do or what characteristics it needs to have. During the early phases of a project, requirements are written by business analysts in terms of how the project must benefit the organization and are typically non-technical. For example, such a business requirement might be "the project must manage appointment scheduling."  Such a statement could describe a well designed notebook as easily as a software product, and this business-centric type of requirement is important to ensure that the initial requirements of a project focus on the needs of the users, and do not bias the project towards any specific solution. Later in the project, business requirements become more technical in order to describe how the system will actually work.

Requirements Analysis

The basic process of analyzing an organization to determine requirements involves three steps:

• Understand the existing situation (the as-is system)

• Identify improvements

• Define requirements for the new system (the to-be system)

To move the users "from here to there," an analyst needs strong critical thinking skills and should not be swayed by previous product experiences or recommendations of solutions that have worked in other organizations.

As an example, consider a project where a user expresses a requirement that the new system must "eliminate overlapping patient appointments." While this might be a worthy goal, the analyst needs to think about it critically. The analyst could first have the users think about circumstances leading to overlaps (two people adding appointments simultaneously to the schedule), and then describe the issues that lead to these circumstances (lack of communication, duplicate scheduling tools). By focusing on these issues, the team is in a better position to develop new business processes that address these concerns. We should note that requirements analysis techniques and requirements gathering techniques go hand in hand. Analysts need to use requirements-gathering techniques to collect information; requirements analysis techniques drive the kind of information that is gathered and how it is ultimately analyzed.

Requirements Gathering Techniques

Requirements gathering can and should be conducted using a number of different techniques. A fact many analysts must contend with is that some information presented by end users may be unreliable, but an even greater problem is the fact that not every expressed need can be addressed in the current project. Using several approaches and involving a wide range of people helps to balance the information gathered to thoroughly inform the requirements gathering process.

Common techniques include:

• Direct interviews

• Group discussions

• Focus groups

• Questionnaires / Surveys

• Direct observation

• Document reviews

Requirements Gathering in Practice

An important consideration before getting to work on gathering requirements is that an analyst should acknowledge the importance of building political support for the project and establishing trust between the project team and the end users of the system. This process may be time consuming and require everyone in the organization to participate, but it should not disrupt the operations of the organization and should be conducted in a way that is convenient and sensible to those helping out.

The analyst should be careful when determining who is included in the requirements-gathering process. The choice to include (or exclude) someone is significant; involving someone in the process implies that the analyst views that person as an important resource and values his or her opinions. You must include all of the key stakeholders (the people who can affect the system or who will be affected by the system). This might include managers, employees, staff members, and even some patients. Also, be sensitive to the fact that some people may have significant influence within the organization even if they do not rank high in the formal organizational hierarchy. If you do not involve a key person, that individual may feel slighted, causing problems during implementation (e.g., saying "I could have told them this might happen, but they didn’t ask me!").

Finally, do everything possible to respect the time commitment that you are asking the participants to make. The best way to do this is to be fully prepared and to make good use of all the types of requirements-gathering techniques. Although, as we will see, interviewing is the most commonly used technique, other indirect methods may help the analyst develop a basic understanding of the business domain so that the direct techniques are more productive. In general, a useful strategy for the analyst to employ is to begin requirements gathering by interviewing senior managers to gain an understanding of the project and get the "big picture." These preliminary interviews can then be followed by document analysis and, possibly, observation of business processes to learn more about the business domain, the vocabulary, and the as-is system. More interviews may then follow to gather the rest of the information needed to understand the as-is system.

Requirement Writing Format

Requirements used in the delivery of IT projects must be written in such a way as to make it perfectly clear what the end product must do. For this reason it is important to remove ambiguity and focus on concrete, observable criteria.

Requirements can be grouped into three categories: business, user, and technical:

Business Requirements

A business requirement is an objective of the project that most closely resembles an existing business process. Business requirements are technology-neutral, meaning that they are written in such a way as to not specify what method will be used to meet the objective. As a matter of fact, a good measure of the usefulness of a business requirement is if it could be argued that a wholly non-electronic solution could satisfy the requirement. An example of a business requirement for an ADT (Admission, Discharge, Transfer) system might read:

The solution should gather and retain all data from patients from pre-admission through their discharge from the facility.

User Requirements

A user requirement describes functionality from the perspective of those people who will be using the project regularly. These should also be technology-neutral, generally speaking, although they are often written to address very specific needs. For the ADT system a user requirement could be:

The solution must permit digitally scanning insurance cards at admission in order to initiate patient record entry.

Technical Requirements

Technical requirements are often the most specific of the requirements needed to build a project, and should provide as specific a blueprint as possible for the developers. Business analysis specialists and the developers themselves are often engaged to write these requirements so that they clearly describe what needs to be built. An example of a technical requirement for the ADT system could be:

The solution must be compatible with input from Medicscan card scanners model 800N, 900, 3000DN.

Many of the requirements in these three categories may overlap, since they may be used by different members of the project team. All of them must be prepared prior to developing the solution, however, since as a body these requirements represent what is essentially a contract for completing the project. Requirements are therefore used not only for planning the exact time and resources needed to build the project, but may also be used to hold the project team accountable for their work once the project is delivered.