Article had been
published earlier with the International Institute of Business Analysis (IIBA)
headquartered in Toronto, Canada and Better Projects , Australia
Every Project Has Requirements
I am sure most of us would agree that “Every Project Has
Requirements”. Every time a new software application is being developed
explicitly or implicitly there is always a ‘Business Analyst’ (BA) from the
project team who performs the role of requirements gathering for every software
project. While some requirements are crucial to the application others are
considered to be gold-plated luxuries.
Determining the project requirements is vital in developing
successful software as they form an agreement between the IT team, the
customers and various stakeholders on what features are absolutely essential to
be delivered in the new system.
Requirements just don’t come from
one source but multiple stakeholders. In this article I would like to touch upon some key
pointers which are essential and indispensable for business analysis. What each
stakeholder’s view is when it comes to determining
software project requirements and who owns them?
Requirements
Stakeholders
From the above figure it is evident
that software requirements just don’t come from the customer. Requirements come
in from all directions which include: Customers, Business Analyst, Pre Sales
Team, Project Manager, Development Team and QA team. It’s imperative that one
identifies at the beginning of the project who takes the ownership for defining
the project requirements. If this is not resolved in the early stages of the
project then the ownership falls on the vendor or the requirements later then form
to be a part of change request.
Customers:
Are They Always Right
Anyone who derives direct or
indirect benefit from a product or service offered is a customer. It’s not
necessary that the customer may be always right. However, the customer has a
viewpoint and one must understand and respect customer’s viewpoints rather than
forcing other stakeholders to determine among the customers who may not necessarily
agree with conflicting project requirements.
As a software customer one would
be primarily responsible for the following activities:
- Customers at
times believe that the analyst or the member from the development team
should already know what the customers need. Defining business
requirements is not the ownership of the customer but the project team.
- It would be
ideal if the analyst is given the pulse of the current systems and
processes coupled with existing documents to educate them about customer’s
business concepts and terminology.
- Customers
usually don’t find it significant to invest time with the project team for
requirements gathering or elicitation activities. Sometimes customers get so busy with their
key responsible areas at work that they usually don’t give justice to the
requirements gathering activity and the requirements gets captured just on
assumptions.
Customer needs to prioritize what
requirements are crucial and critical to the project. Requirements, which are
vital, need to be delivered on priority whereas those that are good to have
features can be delivered phase wise. Customers have to understand that not all
requirements can be given at the same time. Phase wise delivery would be ideal.
Business
Analyst: Catalyst for Requirements
The Business Analyst holds the
primary responsibility to elicit, analyze, validate, specify, verify, and
manage the real needs of the project stakeholders, including customers and end
users. The requirements analyst serves as a catalyst between the customer and
the software development team and is responsible to bring all the stakeholders
to a common level of understanding.
A Business Analyst would serve as
an agent and views requirements from the following angle:
- Apart from
requirement gathering, interviewing the users they would be responsible to
create prototypes or wire frames to demonstrate a non-working model to the
customers. Customer can get a fair idea looking at the wire frames how the
proposed solution would look like.
- For any queries
or concerns towards any aspect of the planned project activity it is
appropriate that a BA defines a clear process in identifying the key points
of contact in the project engagement with proper escalation mechanism.
- Business Analyst
(BA) analyses, documents, manage and presents the project requirements for
review and approval to the customer in a most comprehensible manner.
Analyst should communicate to the customer in the early stages of the
project the standard templates and requirement management tools they would
adhere to in order to document the requirements specifications.
- For a BA getting
a requirements sign-off would mean a formal agreement with the project
stakeholders, stating that the contents of the requirements document, as
drafted, are complete to the final projections and that there are no open
issues left to be addressed. It is an expression of the output of
requirements gathering to all those concerned with the project.
Pre Sales
Team: Before Development Starts
Requirements given by the pre
sales consultant many times conflict with what the developers think and they
could build. The problem here is only a high level input is provided from the
consultant having not much visibility of the product to be developed.
A Pre Sales Consultant would
usually view the project requirements from the following angle:
- They conduct
requirement analysis and pre-assignment studies at customer’s location by
giving product demonstration and walkthroughs to prospective clients,
resolving pre-sales issues and handling questions differentiating our
product from other competitors.
- Pre sales are
also responsible to respond to prospective customer questions and
observations. They educate customers and prospects understanding the
benefits of the product.
- Provide help in
giving feedback to stakeholders regarding the product features and
functions and ensure that the product offered best matches the customer
needs.
- Once a
particular product is successfully implemented the pre sales view the
project requirements in identifying sales opportunity for the product,
prepare proposal documents and market the same in competitors market
falling under the same vertical or domain.
Project
Manager: A Quantitative Analysis
Project Manager’s view to invest
more efforts of the project plan for software development rather than giving
adequate time frame for gathering software requirements. Project manager’s view
requirements by doing a quantitative analysis and its associated impact on the
project plan.
Some of the challenges faced as
far as requirements go from a Management View as are follows
- Project Manager would
view requirements in terms of the cost of the resources involved and the
time frame it would take to implement functionality
in line with the defined standards and control processes.
- Requirements
serve as the baseline for a successful project design. Project Manager
should ensure that the resource who would be dealing with requirement
gathering should have some hands on experience in requirements engineering
practices and that the same is well understood and well communicated.
- Project Managers
have to ensure that as and when one incorporates new project requirements
is the project team able to still stick to their original schedule as per
the available resources. If not then they should immediately renegotiate
on project commitments wherever there is a change in the requirements.
- Managers need to
thoroughly review the project documents prepared by the analysts and
should there be a discrepancy they should communicate the same in the
early stages of the project itself otherwise it would result only in
re-work and detrimentally effecting the on going project delivery.
Development
Team: Requirements to code
Developers are those members of
the community who are more inclined as well as responsible for writing and
coding individual programmes from specific requirements.
After review they interpret
written business requirements and technical specification documents and perform
coding.
- Developers view
the requirements from a technical angle in terms of data dictionary,
tables, user interface, reports formats, integration etc. When questions
like these are raised during the time of requirement gathering they
witness a total disconnect because not at all business users are
technically educated. Discussions like these only dilute the interest
level of the conversation.
- Ambiguity in
requirements results in waste of time and developers end up developing a
solution, which does not meet up with the customer’s requirements.
- Developers at
times end up giving more than what is required by the customer in an
attempt to please them with “gold plated” functionality. One should
deliver only what has been asked for and anything extra that is delivered
should be given only with prior customer approval.
- Some features
required by a customer may have technical limitations and the turn around
time required to implement the same may also be quite high. Certain new
requirements can detrimentally effect the performance of the existing
functionality. To avoid such cost of re-work a requirements stakeholder
should respect the developer’s view of the requirements.
QA Team: A benchmark of quality
Well-defined project requirements
should enable the QA team to develop accurate test cases to verify the
functionality under consideration. It is vital that the testing team be
involved in the project from the requirements elicitation milestone.
The quality team views the
requirements from the following aspect.
- What ever may be
the requirements the quality team would view for the following key
attributes which includes the system’s performance, response time,
handling load, transactions of the system and much more.
- After studying
the business requirements and review of the specifications the testing
team starts with planning, designing, and executing tests cases for
features that need to be released upon customer’s requests.
- Where developers
may have developed in one way the testers expect the product to behave
differently from what the developers have developed as per acceptance
criteria.
Some times very little time is
given for the testing team to test the solution. In case the project is running
behind schedule the testing milestone may be not given due importance.
Conclusion
From the above it can be seen
that different stakeholders interpret project requirements in different ways.
Each one of them is right in their very own way and each one of them has their
viewpoints from their own angle. For the success of the project what is more
important is to have all the stakeholders of the project brought to a common
level of understanding and work in synergy. It's better to identify in the
early stages of the project who from the customer's end would take business
decisions on project requirements so as go ahead smoothly with the next planned
project activity.
