I work for a small company as a software engineer. Our company doesn't have a business analyst or a project manager. We are about to sell a custom CMS system to a very IT illiterate customer.

Who is responsible for creating the requirements specification? If it's a project manager or a business analyst, who should fill this role and how can we avoid any problems as a result?

  • 4
    Hi Mat, welcome to Project Management SE, the Q&A site for questions in the field of project management. I edited your post a bit to focus more on solutions instead of just building a list of problems. Not only should this get you better answers, but it also fits our Q&A format much better. Good luck, and welcome to PMSE! :)
    – jmort253
    Commented Jan 7, 2013 at 3:54

11 Answers 11


Responsibilities for Specifications

The customer is ultimately responsible for specifying requirements. Whether your company has a business analyst or project manager is irrelevant to identifying the responsible party.

A business analyst is generally a liaison between the development team and the client, and is responsible for working with a client to elicit or refine requirements. However, the requirements themselves always originate with the client. In many cases, the business analyst is in the best position to document the requirements once they've been defined, but that is really a matter of convenience and is ancillary to the role.

Put another way, the business analyst facilitates requirements-gathering and refinement of the deliverable specifications from the client. The client remains responsible for defining their needs and expectations.

The project manager, on the other hand, has the responsibility for managing the specification artifacts (e.g. storing and disseminating the specification documents, if any), and for integrating the specifications into the project plan. As before, the client is responsible for the specifications; the project manager just facilitates the inclusion of specifications into the project management process.

  • 2
    CodeGnome makes a good point here - ultimately the client needs to decide what they want the system to do. I think the key to 'avoiding problems' will be to ensure that whoever elicits and documents the requirements does so in a way that is understandable to non-technical client representatives. User stories (mountaingoatsoftware.com/topics/user-stories) are good for this reason because they abstract client requirements from technical implementation.
    – Willl
    Commented Jan 8, 2013 at 11:14
  • 1
    While I feel that the customer being responsible is the perfect world answer, the reality for me has often been different. I've worked with several customers who won't even look at requirements specifications let alone give input into them. They come into the project with one or two paragraphs describing the product they want, have an hour or so kick-off when you can ask them questions and then they go hands off until reviews leaving us to drill down into detailed requirements. I've found scrum to help decently here as the whole process is built around keeping the customer involved.
    – NightMan
    Commented Jan 10, 2013 at 17:50
  • @NightMan If your customers aren't contractually responsible for specifications, you probably need to carefully review your engagement practices. Guessing what the customer wants is generally not a successful strategy.
    – Todd A. Jacobs
    Commented Jan 10, 2013 at 17:55
  • To add (cause I ran out of room) - I feel like anyone on the team potentially could be responsible for requirements. Whoever has the best handle on what the customer(s) want would be the best choice - whether that's a developer, tester, project manager or business analyst. I've seen it done by each in my career and the reason it works or doesn't work solely depends on how much the person can identify what the customer(s) truly want and then document it in such a way that engineers can translate them into a functioning product.
    – NightMan
    Commented Jan 10, 2013 at 17:58
  • @CodeGnome Oh, you're absolutely right and I've been on failed projects because of exactly that. Unfortunately, the team rarely gets to make the decision on what customers to do business with. Many executive teams out there see only the dollar signs and don't care if the customer is difficult or not. I've been told "just do the best you can" many times when I've reported lack of customer involvement.
    – NightMan
    Commented Jan 10, 2013 at 18:02

Ideally I think you'd want someone who isn't a direct part of the development team to be gathering requirements. This is partly because requirements should (depending on your precise situation) go beyond the technical needs of the project to the business needs of the client - something that developers/engineers may not be best placed to advise on. I'm fairly agnostic on whether this process should be undertaken by a business analyst or project manager. I've been in situations - particularly in small organisations - where these roles overlap or are performed by the same person.

Since you have neither resource available to you I think you need to identify someone whose role - as far as possible - spans both business and technical domains. If you work in an agile environment I wonder if a scrum master or similar might be the most appropriate person. Alternatively the role could be split between someone on the technical side (e.g. you!) and someone in a sales or account management role. This would provide a range of views (with sales/accounts helping to document the 'why' and technical helping to document the 'what' and 'how') and ensure that the 'IT-illiterate' client doesn't get too lost in the details.

  • And also, someone that is in relation with your clients. This important to say because sometime the BA doesn't have any direct access to final client. And sometime the person doing the development is the one talking to client. Commented Oct 17, 2022 at 3:17

Customer IS responsible for requirements; however, it is the company's responsibility to organize them and translate into a technical language.

Agility of development is a must in the current subset; therefore, make sure that customer gets to see and approve every step of the development (working prototypes).

It would be much easier to answer if we knew who else is the part of the process, meaning - what positions are there in the company? A software engineer cannot be a requirements elicitor (he/she can theoretically, but it is proven to be counterproductive in most cases. One of the reasons - the tendency is to minimize the coding workload; therefore, the product and customer satisfaction suffer).

Instead, someone in the company, who is not technically illiterate, and at the same time can speak business language, should perform the duty of BA. For instance, it can be a sales person who is familiar with the production. But my advice is to contract a BA for requirements.

  • Hi Bob, welcome to Project Management SE, the Q&A site for questions in the field of project management. I edited your question a bit to clean it up so that your ideas would be best presented. Hope to see you continue to contribute on our site! Welcome! :)
    – jmort253
    Commented Jan 10, 2013 at 5:19
  • Does that mean the BA does not need to have deep knowledge of how a specific company works? Everytime we've had external BAs at my current company, they've fallen in the same traps we (IT) did, only touching the surface of requirements, and it led to anger and frustration on all sides.
    – leokhorn
    Commented Jul 10, 2018 at 14:19

In the absence of a PM or a BA, the person(s) who has done functional testing on the product is a good choice for drafting the requirements specs. They can easily reverse engineer their functional test specs into requirements specs.

If this formal process ( of having documented functional specs and subsequent functional testing)is not in place, the engineers who build the product are the ones who should document requirements.

As a side note, if you are selling a product to an IT-illiterate customer, a better format for documenting requirements is a user manual or user help document that will help the user navigate the system.

  • A manual tells an end-user how to use a system. It doesn't replace a specifications document, which describes what the system ought to do.
    – Todd A. Jacobs
    Commented Jan 7, 2013 at 19:25
  • @CodeGnome : Right. But what is a better format for an IT illiterate customer - a bunch of "shall" statements or a way to understand the structure and function of the system?
    – moonstar
    Commented Jan 8, 2013 at 6:26
  • 1
    Unless you have either a detailed specification or a working system to document, the "manual" will most likely be a work of pure fiction bearing little resemblance to anything actually delivered. YMMV.
    – Todd A. Jacobs
    Commented Jan 8, 2013 at 6:35
  • A developer who has worked on the product would most certainly not produce "pure fiction" when coming up with documentation for that product. YMMV.
    – moonstar
    Commented Jan 10, 2013 at 7:22

Adopt agile values Everyone in the team should be responsible for bringing value for the customer and not developing non-sense. You have to speak to your customer. You have to provide working software - not future-complete, but working - as soon as possible, so you can receive feedback from the customer. You have to talk with the users of the CMS; with the people that will actually use your software. You can create mockups instead of software, to check the interactions your users expect and to show them what the software will look like.

  • Hi Darhazer, are you saying that everyone in the team is responsible for writing the requirements document in the absence of the PM and business analyst?
    – jmort253
    Commented Jan 10, 2013 at 5:10

Based on my personal experience as a project manager, it is generally the business analyst who is responsible for writing up the business requirements specifications. The project manager is responsible for ensuring that business analyst delivers the business requirements specifications on schedule, signed off by all parties and shared with software development team for analysis.

  • 2
    Hi DL. Welcome to PMSE. Can you expand on how you think Mat should approach this problem in the absence of a business analyst? From your experience could someone else perform this role?
    – Willl
    Commented Jan 7, 2013 at 10:29

It depends on the methodology and the context. Is this an Agile/Scrum project? Is this a Waterfall project? Is this a Agilefall project?

Getting requirements right seems to a major problem for any project using any methodology. The only common thing in all of them is to provide "an result" early and get feedback. If either the requirements (and/or user story) have changed or the requirement was misunderstood then early feedback will move the requirement towards what the customer really needs solved.

So when in doubt "iterate" soon and often!

Yes, I understand that doesn't work easily or at all when there is no visible input/output on a project.


  • "common thing in all of them"... While I'm not an expert in Waterfall, isn't the point of Waterfall to try to get requirements as accurate as possible the first time, because feedback is going to be late? That's the advantage of Agile - earlier feedback.
    – Sarov
    Commented Nov 1, 2016 at 19:17

Nice question!

BRD (Business Requirement Document) and FRD (Functional Requirement Document) are the two types of documentations needed. Both BRD and FRD are carried out by a Business Analyst and not by Project Manager. I have also observed that many companies ask their Project Manager or UX Designer to carry out these responsibilities which ideally belong to Business Analyst. Business Analyst is the one who is expected to elicit and refine the business requirements by building a strong rapport with the client.

Few roles of the Business Analyst (BA):

  1. Liaising with the Designing/Development Team for the technical aspects/issues/fixations/changes/advises/suggestions/insights/etc.
  2. Liaising with the Project Manager for knowing the status of project.
  3. Building a rapport with the Client. BA is a liaison between Client and Developers/Project Managers/Designers.
  4. Budget Analysis & Requirement Specification Analysis.
  5. Stakeholder Analysis.
  6. Risk Analysis.
  7. Documentation work: BRD, FRD.
  8. Wireframing (optional, because UX Designers are meant to be the responsible people for wireframing.)
  9. Personally carrying out an UAT (User Acceptance Testing).

I have seen many small companies or start-up companies asking their employees to wear as many hats as they can! But If you are not comfortable with a particular role, then you should straightaway let them know about your concern!


As a Senior Business Analyst (BA) with over two decades of experience as BA (did a little PM work, but prefer being a BA, is my passion), I can tell you that the only one responsible for gathering business requirements specifications is the BA (and that means Functional, Non-Functional, and Technical Specifications, including Use Cases, Flow Charts, etc.). The BA prepares a Business Requirement Document (BRD) and needs to be approved by the client, to ensure that all his/her needs are being met.

It is true, the requirements start with the client, as they are the ones in need of a solution to their current situation, however, the client does not speak technical and technical does not speak business, thus, the bridge is the Business Analyst. S/he has the skills needed to speak both languages, and collect all requirements, negotiate requirements, and come out with a recommended solution (or multiple solutions) from which the client will choose.

In the BRD, all information (not just requirements) must exist (Use Cases, Diagrams, specially flow charts, etc.). This is to ensure that when the solution is implemented there will be no gaps and it is the appropriate solution the client needs and to ensure that it is built with strong scalability to continue to improve it as time goes on.

  • Welcome to PMSE! Another way of looking at this is that requirements and specifications will be developed on an ongoing basis as work proceeds and may not always be in the form of a single document. Documentation could be in a wiki or in detailed stories on a backlog. The whole team have a role to play in keeping documentation up to date. For example BAs won't necessarily create data models or final mapping documents for data integration processes.
    – nvogel
    Commented Jul 15, 2021 at 16:11
  • At condition the BA has access to client. I'm working in a company where only sales can talk to clients. In this case the sales are responsible of specification. In general, without mentioning any role, the specification responsible must be the client or the person in contact with the client. Commented Oct 14, 2022 at 8:31

In Agile, everyone is responsible for bringing value to the customer's project. However, in a more traditional sense, the Business Analyst has been more directly responsible for eliciting the requirements, translating them against suggested solutions, and working with the system architect/project manager/lead programmer. In some cases the role of the Analyst will go further in helping to create documentation, and training materials on the resources that were created as they are supposed to be the closest to the end user. If there is a specification that your team is using specifically to handle Requirements, the Business Analyst would be the closest role to this document.

A Project Manager on the other hand looks at the full picture of the project to create the necessary environment for everyone to do their job. They would be responsible for managing all documents created by the team, organizing them and agreeing on a single format, interfacing with your final customers, gaining their sign off on what can and can't be done, as well as mitigating any obstacles that might prevent tasks from being completed. In the end, they are two separate roles that will be working closely together.


The bottom line is that the Business Analyst MUST get the specs right.

In other words, he/she needs to write the specs so they do exactly what the customer wants and then...

The Customer is responsible for signing these of.

However, if the specs are vague or inaccurate, and even if they are signed off, the Customer is always right. A cliche I know but true.

As they're paying the bill, they can make mistakes but your BAs can't.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.