by Anupama Weerabahu

Last week, we read about the good requirements – the characteristics of an individual requirement and a set of requirements, and guidelines for writing good requirements. However, in practice, many software problems arise from shortcomings in the ways that people gather, document, agree on, and modify the product's requirements – and thus these cannot be labeled as good requirements. The important actor involved in the process of gathering, documenting and analyzing requirements is the Requirement Analyst. In today’s article, we will discuss about the role of the requirement analyst and the skills that the requirements analyst needs to possess in order to deliver right output at the end.

The Requirement Analyst: Overview

In every software development project, there is a person who is responsible for gathering the requirements and forwarding them to software engineers in a suitable way. Simply, the requirement analyst role exist for every project and could be either explicit or implicit. The mature software corporations identify specialists called ‘Business Analysts’ to perform this function where as in some product development organizations the marketing staff and production manager provides the requirements. Other synonyms that are used in the field to refer to requirements analyst include ‘systems analyst’, ‘requirements engineer’, ‘requirements manager’ or just the word ‘analyst’.

The analyst can be seen as the translator of one’s perspectives to a requirement specification, which provides input for some other stakeholders and reflector of the compiled information to the original stakeholder. Basically analyst helps stakeholders to find the differences between what they say they want and what they really need. Analyst he himself learns a lot and educates, questions, listens and organizes the others a lot. Truly speaking, analyst job is a tough job with a high degree of responsibility.

 

The Requirement Analyst Role

The requirements analyst has the primary responsibility to gather, analyze, validate, specify, verify, and manage the real needs of the project stakeholders (including clients and business users).

According to Karl Wiegers, the analyst serves as the principal conduit through which requirements flow between the customer community and the software development team and he has depicted the relationship among the different parties involved, using the below diagram.

Thus, the requirement analyst, plays a major role in collecting and disseminating the product information. However, Project Manager coordinates among the stakeholder and communicates project information. Further, the requirements analyst is responsible for seeing that the tasks are performed properly.

The Analyst's Tasks

The norm is that the requirements analyst bridges the gap between the software engineer and the client. In order to do this, the analyst first needs to understand the users intentions for the new system and secondly needs to analyze and define the functional and non-functional requirements. The out put of the requirements analyst will be extensively used by the projects managers to estimate the resource requirements, software engineers to design and build the system as required and testers to verify the product and test it.

The given below are the main tasks of the requirements analyst.

1.     Define business requirements: It is the duty of the business analyst to help the project management/marketing to realize the high level business requirement of the organization. This can be presented with a scope document and vision and objectives of the system can be stated there.

2.     Identify project stakeholders and user classes: Then the analyst can use the initial scope document to identify the different user classes involved in the system and all the stakeholders of the project. After identifying the relevant user classes the analyst, should then gather information about these users and create a pool of representatives, by taking at least one from each user class. Then these project members need to be made aware about their responsibilities at the requirements stage of the product.

3.    Elicit requirements: It is then the responsibility of the analyst to meet up with the users and help them to articulate the system capabilities expected in order to meet the business objective. At this stage the different requirements gathering techniques can be used by the analyst. One or more of the following can be used by the analyst, depending on the nature of the project, the domain knowledge, criticality and the users awareness, etc.

Users naturally emphasize the system's functional requirements, so steer the discussions to include quality attributes, performance goals, business rules, external interfaces, and constraints. It's appropriate to challenge user assumptions, but don't try to force your own beliefs on the users. Some user requirements might seem absurd, but if the user confirms that they're correct, there's nothing to gain from pushing the point.

4.     Analyze requirements: After gathering the requirements, it is the duty of the analyst to check the logical sequence of what client has requested, unmentioned requirements, vague and weak requirements etc. If conflicting requirements are found, the client needs to be interviewed again and resolve all the doubts. At this stage, all the business rules and processes, and the system in-outs needs to be realized by the analyst.

5.    Write requirement specifications: Once the requirement is identified fully, then the analyst is responsible for writing well organized specification which clearly explains the system to be developed. This document once signed off from the customer will be regarded as the guideline for product development and quality assurance.

6.     Model the requirement: Further to documentation, the analyst needs to develop data models, tables and equations, etc. that can be used to depict the system at a higher level. Use of a standard modeling language is recommended.

7.     Lead requirements validation: The analyst is considered to be the agent of the client for the system to be developed. Thus the analyst needs to collaborate well  with the software engineers, quality assurance engineers, designers etc, at each phase of the project to make sure that the system develop has a compliance to the stated user requirements. This is important; because different people might interpret the same thing differently.

8.   Facilitate requirement prioritization: As we saw so far analyst is the best person to prioritize the requirements according to the users requirement. Because analyst has the understanding of what is required by the client and what needs to be delivered first.

9.    Manage requirements: After establishing the baseline of the requirements, the analyst has to keep track of modifications, enhancements and additions to the finalized requirements as per the client requirement and inform the project team for scope modifications.

Essential Analyst Skills

As I have mentioned earlier, requirement analyst job is a tough job. Thus it is not reasonable to expect any person to serve as an analyst without proper training, guidance and experience. Particularly, analyst needs to be aware of the different requirement eliciting techniques and tools, modeling etc. Further, an effective analyst needs to be a strong communicator and a facilitator. These interpersonal skills together with technical and business domain knowledge create the right candidate for the job. Patience and a genuine desire to work with people are key success factors; the job involves lot of interaction with lot of people, who are coming from different backgrounds and statuses.

    Some of the skills that are important for an individual to become a good requirements analyst as identified by Karl Wiegers are given below.

10.    Listening skills: To become proficient at two-way communication, learn how to listen effectively. Active listening involves eliminating distractions, maintaining an attentive posture and eye contact, and restating key points to confirm your understanding. You need to grasp what people are saying and also to read between the lines to detect what they might be hesitant to say. Learn how your collaborators prefer to communicate and avoid imposing your personal filter of understanding on what you hear the customers say. Watch for assumptions that underlie either what you hear from others or your own interpretation.

11.    Interviewing and questioning skills: Most requirements input comes through discussions, so the analyst must be able to talk with diverse individuals and groups about their needs. It can be intimidating to work with senior managers and with highly opinionated or aggressive individuals. You need to ask the right questions to surface essential requirements information. For example, users naturally focus on the system's normal, expected behaviors. However, much code gets written to handle exceptions, so you must also probe for possible error conditions and determine how the system should respond. With experience, you'll become skilled in the art of asking questions that reveal and clarify uncertainties, disagreements, assumptions, and unstated expectations.

12.    Analytical skills:  An effective analyst can think at multiple levels of abstraction. Sometimes you must drill down from high-level information into details. In other situations, you'll need to generalize from a specific need that one user described to a set of requirements that will satisfy many members of a user class. Critically evaluate the information gathered from multiple sources to reconcile conflicts, separate user "wants" from the underlying true needs, and distinguish solution ideas from requirements.

13. Facilitation skills:  The ability to facilitate requirements elicitation workshops is a necessary analyst capability. A neutral facilitator who has strong questioning, observational, and facilitation skills can help a group build trust and improve the sometimes tense relationship between business and information technology staff.

14.   Observational skills:  An observant analyst will detect comments made in passing that might turn out to be significant. By watching a user perform his job or use a current application, a good observer can detect subtleties that the user might not mention. Strong observational skills sometimes expose new areas for elicitation discussions, revealing additional requirements that no one has mentioned yet.

15. Writing skills:  The principal deliverable from requirements development is a written specification that communicates information among customers, marketing, managers, and technical staff. The analyst needs a solid command of the language and the ability to express complex ideas clearly.

16.   Organizational skill:  Analysts must work with a vast array of jumbled information gathered during elicitation and analysis. Coping with rapidly changing information and structuring all the bits into a coherent whole demands exceptional organizational skills and the patience and tenacity to make sense from ambiguity and disarray.

17. Modeling skill:  Tools ranging from the venerable flowchart through structured analysis models (data flow diagram, entity-relationship diagram, and the like) to contemporary Unified Modeling Language (UML) notations should be part of every analyst's repertoire. Some will be useful when communicating with users, others when communicating with developers. The analyst will need to educate other stakeholders on the value of using these techniques and how to read them.

18.   Interpersonal skills:  Analysts need the ability to get people with competing interests to work together. An analyst should feel comfortable talking with individuals in diverse job functions and at all levels of the organization. He or she might need to work with distributed virtual teams whose members are separated by geography, time zones, cultures, or native languages. Experienced analysts often mentor their new colleagues, and they educate their customer counterparts about the requirements engineering and software development processes.

19.    Creativity:  The analyst is not merely a scribe who records whatever customers say. The best analysts invent requirements (Robertson 2002). They conceive innovative product capabilities, imagine new markets and business opportunities, and think of ways to surprise and delight their customers. A really valuable analyst finds creative ways to satisfy needs that users didn't even know they had.

With the description of these essential skills of a requirement analyst, today’s article ends.  In the next article we will dig deep into the first role of the requirements analyst – defining business requirements.  Till then happy reading!

Reference Materials: