Yes! Requirements Engineering is composed of four key activities – Requirements Elicitation, Requirements Analysis and Negotiation, Requirements Specification or Documentation and Requirements Validation.
Requirement Elicitation is to discover system requirements through consultation with stakeholders. Some of the sources of this discovery could be system documents, domain knowledge and market studies. Requirement Analysis and Negotiation is to analyze requirements in details and negotiate them with stakeholders on which requirements are to be considered. Requirement Specification or Documentation is to document agreed requirements at a certain level of detail. Requirement Validation is to review or validate requirements for clarity, consistency and completeness.
This is an attempt to address a set of key areas where things can go wrong during Requirements Engineering.
Who Plays the Role? Sometimes, project teams go by the assumption that every skilled programmer is also proficient at interviewing customers and writing requirements specifications. This is a risky assumption. This may not yield good results in all cases.
Training alone would not suffice: Requirement Analysts are grown – not just trained! A good training in various areas related to requirement analysis is mandatory but not sufficient. This includes training sessions on business, software engineering as well as soft skills. A requirement analyst needs to be aware of the business domain, technology aspects as well as user expectation management. Soft skills such as effective listening, negotiating and facilitating, help analysts uncover users’ unspoken desires. Thus, training alone would not suffice. Adequate mentoring and coaching is required to groom Requirement Analysts. Requirement Analysts grow to higher levels based on their work experience in performing their role effectively – a good training is just a starting point.
Focus on Soft Skills: Most of the times, due to factors such as information over flow, analysts focus more on business requirements itself and lose focus on their soft skills. Soft skills such as listening, interviewing and questioning, analytical reasoning, facilitation, observation, writing, organizing, modeling, interpersonal intelligence, collaboration and creativity are to be consistently honed to conduct requirement analysis effectively.
Planning: Requirement Analysis needs thorough planning. Typical deliverables need to include traceable requirements, open issues, open queries - in addition to other artifacts. Formal reviews need to be planned to ensure quality before design. Often analysts rely on a series of meetings to perform Requirement Analysis. This is not sufficient. Various techniques such as user interviews, demonstrations, walk-through of live data and processes, etc., are to be considered while planning.
Inadequate Elicitation: Inadequate or elicitation will result in poor specification. Requirement elicitation consists of fact-finding, information gathering and integration. Identification of various sources of requirements (such as end users, interfacing systems), gathering requirements and integrating them is key to the success of Requirement Analysis. Inadequate Elicitation could be the result of factors such as ineffective meetings, not asking relevant or revealing questions, not scooping, not modeling, not prioritizing etc. Some of such key factors have been explained below.
Ineffective Meetings: Effective meetings ensure progress. Requirement Analyst needs to plan effective meetings with a manageable list in the agenda and ensure that all action items are followed-up and closed.
Not Asking! Many experts provide the tip – ‘Communicate, Communicate & Communicate’ to ensure project success. Requirement Analysis (as well as any other phase in a project) can go wrong when the team members (more specifically the Requirement Analyst) do not ask questions. Thus the tip for successful analysis is ‘Ask, Ask, Ask’ – specifically, ask revealing and relevant questions. Asking good questions to explore and understand detailed requirements provide the base for thorough testing. Both the type and timing of questions are very important. Questions related to requirement originating during Integration Testing are not uncommon in projects. It is good to identify, ask and resolve queries during early stages of the project. The book ‘Exploring Requirements: Quality Before Design’, Dorset House, 1989 by Donald Gause and Gerald Weinberg is worth reading to understand this aspect.
What, How and When? Sounds simple to follow – but this is forgotten at times. Analysts capture ‘What is required’ – but they forget ‘How’ and ‘When’! Here is an example. The business users want an email notification facility that sends an email notification whenever a user is registered into the system. The analyst captures the ‘What’ factor which goes in to the FS document ‘A email has to be sent whenever a user is registered into the system’. During acceptance testing, the user elaborates on the ‘How’ factor and says - ‘…the system should detect the delivery status of such emails and resend the mail until it is delivered successfully. The email message should contain few dynamic links as well as a logo. The users should have an option of not receiving such emails’ and stresses that he wanted the email functionality to work this way in the initial delivery itself. This is reported as a critical issue and the project team works late nights to provide this functionality. In this example, initially the analyst should have given adequate stress on the ‘How’ and ‘When’ factors that help him focus on elaborating the requirement. This happens when the analysts focus on ‘elicitation’.
Not Modeling! Modeling is done across industries and disciplines. Requirements need to be modeled using appropriate techniques and tools. A textual description may not be adequate in all instances. Use Modeling. Use examples, illustrations and substantiate them with good data.
What is the Scope? Things can definitely go wrong when the analyst gathers exhaustive requirements but fails to qualify if all of them fall under the scope of the project. This could lead to misunderstanding, overruns and poor quality. Requirement Management: Requirement Analysis as a project phase need to end with a set of baselined requirements. Still, Requirement Management activity progresses until acceptance of the end product. Loosing focus on Requirement Management may lead to conflicts and poor quality.
Communication Gap: Requirement Analyst acts as a bridge between the end-users and the project team. The objective is to transform user requirements in to system requirement specifications and ensure good quality of traceable requirements so that end-users get what they wanted. Any communication gap in this area could result in customer dissatisfaction.
Not Prioritizing! Not prioritizing requirements is a potential risk, as the project team has no means to handle design, implementation and testing issues. Prioritization cannot be overruled in any project.
Missing out Non-Functional Requirements: A project cannot succeed with high-quality functional requirements alone. Non-functional requirements play crucial role in planning design, coding and testing activities. Non-functional requirements fall in to categories such as Reliability, Scalability, Installability, Useability, Availability, Performance, etc.
Missing Assumptions, Dependencies and Constraints: Identification, elicitation and documentation of assumptions, dependencies and constraints is a vital part of Requirement Analysis. It is a good practice to understand the list of assumptions, dependencies and constraints specified in project proposal or statement of work & plan meetings to discuss all assumptions, dependencies and constraints pertaining to project requirements. Missing assumptions, dependencies and constraints would guarantee chaos and customer dissatisfaction.
Inadequate Validation or Reviews: Validation of requirements is the responsibility of the Requirement Analyst. The relatedness and conflicting nature of requirements are to be identified and resolved during initial stages. All artifacts of Requirement Analysis are to be reviewed to identify and resolve defects.
Not Measuring the Quality of Requirements: Quality of requirements affect the quality of subsequent phases. Quality of requirements can be measured using organizational metrication process in organizations that follow standards such as CMM.
Not documenting “What is not in scope”: It is a good practice to document the list of things that are out of scope. During meetings with the stakeholders or end users, a set of features may be qualified for subsequent phases of the project. If not documented, such features may creep in during the time of project execution or acceptance testing. It is good to document all such features and get a sign-off to mitigate requirements creep.
Not focusing on ‘Technical Requirements’: Technical requirements are vital for the acceptance of the system. Such requirements could be related to areas such as compatibility, coding standards, error handling and propagating errors with user-friendly messages, audit trial, data interfaces, design of multi-currency support, design of multi-lingual support and UI design. Requirements Engineering needs to consider technical requirements with respect to what the stakeholder want on technical perspective. Design Phase would address these requirements with respect to how they would be implemented. Thus, the identification and documentation of technical requirements should not be forgotten or pushed to Design Phase.
Needless to say, practitioners need to focus on these areas to mitigate risks related to Requirements Engineering. Any thoughts?
Other Posts on Requirements Engineering:
