Best Practices for Requirements Analysis/Gathering

Best Practices for Requirements Analysis/Gathering

Best Practices for Requirements Analysis/Gathering

 

Venugopal Anthana

 

The initial phase of the Software Development Life Cycle (SDLC) life cycle is called “Requirement Analysis,” also referred to as “Requirement Gathering.” This is perhaps the most vital phase within the SDLC, because it lays the foundation for how the rest of the software project will take place. Who will give these requirements and how, you ask? There are several approaches. It should be noted that this phase is also the most common for making mistakes within the project. By using the following techniques and methodologies, you can avoid getting de-railed by these mistakes. 

Here are the various requirement analyzing techniques that can be used as per the Software Development process: 

·        Business Process Modeling Notation (BPMN)

·        UML Use Cases

·        Flow Chart

·        Data Flow Diagrams

·        Role Activity Diagrams

·        Work Flow Technique

·        GAP Analysis

Business Process Modeling Notation

This technique is similar to creating process flowcharts, although BPMN has it’s own symbols and elements. Business process modeling and notation is used to create graphs for the business process. These graphs simplify understanding the business process and end to end business flow. BPMN is widely popular as a process improvement methodology.

UML (Unified Model Language)

UML consists of an integrated set of diagrams that are created to specify, visualize, construct and document the artefacts of a software system. UML is a useful technique while creating object-oriented software and working with the software development process.  In UML, graphical notations are used to represent the design of a software project.  UML also help in validating the architectural design of the software.

Flow Chart

A flowchart depicts the sequential flow and control logic of a set of activities that are related. Flowcharts are in different formats such as linear, cross-functional, and top-down.  The flowchart can represent system interactions, data flows, etc. Flow charts are easy to understand and can be used by both the technical and non-technical team members. Flowchart technique helps in showcasing the critical attributes of a process.

Data Flow Diagrams

This technique is used to visually represent systems and processes that are complex and difficult to describe in text. Data flow diagrams represent the flow of information through a process or a system. It also includes the data inputs and outputs, data stores, and the various sub process through which the data moves. DFD describes various entities and their relationships with the help of standardized notations and symbols.  By visualizing all the elements of the system it is easier to identify any shortcomings. These shortcomings are then eliminated in a bid to create a robust solution.

 

 

 

 

Role Activity Diagrams

Role-activity diagram (RAD) is a role-oriented process model that represents role-activity diagrams.  Role activity diagrams are a high-level view that captures the dynamics and role structure of an organization. Roles are used to grouping together activities into units of responsibilities. Activities are the basic parts of a role. An activity may be either carried out in isolation or it may require coordination with other activities within the role.

Work Flow Technique

Work Flow Technique is represented that how the business process gives maximum understanding the business. In each step there will be complete information about the business, in other words it give us the how the software project works and tells us the where to start and end points. This is one of the best technique to understand the requirements easily.

GAP Analysis

Gap analysis is a technique which helps to analyse the gaps in performance of a software application to determine whether the business requirements are met or not. It also involves the steps that are to be taken to ensure that all the business requirements are met successfully. Gap denotes the difference between the present state and the target state. Gap analysis is also known as need analysis, need assessment or need-gap analysis.

JAD sessions

Joint Application Development (JAD) is basically a process in which the customer is involved in the application development by a series of workshops. The JAD methodology enables a rapid development, and enhanced customer contentment, since the customer is continuously involved in the project. The requirements of the system are investigated, and the application is developed with the input from customer by a sequence of interviews. JAD sessions are usually used for multiple fields where customer agreement is required. This includes business requirements gathering, case studies, creation of execution plans, development of quality plans, etc. The primary aim of JAD sessions is to decrease the time needed for the completion of deliverables. Normally, the JAD sessions are expensive compared to other methods, like brainstorming techniques, due to the additional costs required for JAD training, and the JAD facilitation team. However, since these sessions are effective, and are completed in a short period of time, these techniques are preferred in some organizations. The requirements of the systems can be documented effectively, precisely, and rapidly, by the JAD sessions, compared to the conventional methodology.

JAD sessions are conducted by arranging a meeting of the concerned subject matter experts, stakeholders, and the key management team, all being available at the same time. These are the people who have the detailed information about the project and its requirements. Time is reduced considerably due to the presence of all these important persons, who can provide valuable input for the project. Therefore, the decisions are facilitated expeditiously by the JAD facilitation team. When the interviewing technique is used, answering questions becomes simpler and a precise solution is available promptly. Questions which may take weeks and months to be answered are settled in a few minutes of discussion.

Here are key roles you need to involve to keep your JAD session on the right track

Executive sponsor

This person is usually the manager of the business area who comes from the customer’s company and has the full freedom to make critical decisions concerning the project.

Although they don’t have to actively participate in all steps of the project, they need to be available throughout the process and solve important issues as they arise.

Facilitator

This is the most important person in the process as they are responsible for planning, executing, and managing the session. The facilitator should have the right knowledge and extensive experience to lead the project. Also, they should work closely with executive sponsors to achieve desired goals. During the discussion, the facilitator should be able to:

·        Focus on the process

·        Be unbiased and neutral

·        Lead groups and keep sessions on track

·        Stop side-line conversations

Stakeholder

Stakeholder is the main focus of the entire process. Without their involvement, JAD sessions are pointless. They represent all key user groups affected by the project development and represent multiple levels within the organization. JAD session allows stakeholders to become an integral part of the project so they can get the product they need.

Scribe (Recorder)

Scribe is in charge of documenting the entire JAD process. Since there are often a lot of ideas and suggestions, a JAD session may involve more scribes. A Scribe must:

·        Capture the important decisions, who made them, and why

·        Distribute and archive the documentation at the end of each session

·        Have excellent analytical skills to be able to analyse the discussion

 

 

 

 

 

IT Representative

IT Representative gives technical advice and helps JAD team develop logical models to build a prototype. They must:

·        Help the customer turn their concepts into business requirements

·        Efficiently use available technology

·        Provide end solutions that are realistic for the budget and timeframe

Observer

This person observes each step of a JAD session, end-user’s needs, and JAD sessions decisions

Advantages

·        JAD allows you to resolve difficulties more simply and produce better, error-free software

·        The joint collaboration between the company and the clients lowers all risks

·        JAD reduces costs and time needed for project development

·        Well-defined requirements improve system quality

·        Due to the close communication, progress is faster

·        JAD encourages the team to push each other to work faster and deliver on time

Disadvantages

·        Different opinions within the team make it difficult to align goals and maintain focus

·        Depending on the size of the project, JAD may require a significant time commitment

Best Practices of Requirement Analysis

·        Create Visual prototypes of interfaces in a storyboard fashion. Much of what we do as IT professionals is hard to understand by business stakeholders, who appreciate visual depictions of the systems and tools they will be using.

·        Meet with as many stakeholders as you can as many times as you need in order to gather your requirements.

·        The most vocal people don’t always know the most. If you are only holding requirements workshops or brainstorming meetings, you may be missing out on great ideas from shy people. Consider the Nominal Group Technique, or perhaps even just one-on-one interviews.

·        A requirement must have only ONE requirement in it. If there is the word “and” in your requirement, it is not testable thus invalid.

·        Be specific about what you need – using flowery language in a requirement only creates ambiguity. For instance, who are you really helping if you write a requirement as “system must be user-friendly?” Sure, you could write it “system must be easy to use” but who are you fooling? It is untestable and not actionable, so invalid.

·        The nature of functional analysis requires ‘progressive elaboration’ — You will have to go back to your stakeholders to VALIDATE their requirements, and that is perfectly normal. Tell them in advance that you have to do this so they don’t think that you are an idiot for coming back for clarification

·        Continue to invest in your internal functional analysis capabilities through training, best-practice process documentation. With each step toward improving your methodology you will gain commensurate benefits in the speed and accuracy with which you implement IT solutions, both as an individual and together with your team.

·        Don’t forget to create use cases, or workflow diagrams – VERY important to understand how people must interact with a new system.

·        Start from a base template for your solution requirements document. A good place to start is the IEEE coops, although it is NOT suitable for every project, certainly not smaller ones. You can create your own variant of it to suit your needs.

·        There will be conflicts among how people see a requirement. Make sure you help facilitate agreement, or that conflict will rear its ugly head after implementation, up to and including project failure. Be mindful of your emotions/adrenaline, since you naturally will have a vested interest in the project’s success, which may affect your ability to be composed in the face of conflict.

 

No Comments

Post a Comment

Comment
Name
Email
Website

seventeen + 18 =

Stay Updated!

Sign up to receive our latest blogs and news. Join our community to receive our content first.