Business Analyst Community & Resources | Modern Analyst

Interview Questions for Business Analysts and Systems Analysts

Recent Interview Questions | Search | Subscribe (RSS)

INTERVIEW QUESTION:

Would you define or document requirements differently, when the intent is to acquire a commercial off-the-shelf (COTS) product rather than build a custom-developed solution?

Posted by Chris Adams

// 27072 Views // 5 Additional Answers & Comments

Categories: Business Analysis, Systems Analysis, Requirements Analysis (BABOK KA)

ANSWER

Generally speaking, yes. There are a few key considerations that drive the way requirements are defined and documented for acquisition of a commercial software system.

Requirements for a commercial product should be ‘informative’ rather than ‘prescriptive’. The software is already built, so the requirements will not be used to design or develop the system but rather to understand the capabilities that a product does (or doesn’t) have, and to compare different products for best overall fit to the business needs. They should be documented as business requirements rather than system requirements, and kept at a relatively high level of detail. Once a solution has been chosen, then more detailed requirements can be documented in a very focused manner in areas where the particular product may need to be configured or customized.

In a formal acquisition process such as a Request For Proposals (RFP), the terminology used to document requirements is also very important. There are a number of standard terms and phrases that carry specific meaning within an RFP which can affect the way that requirements are worded. In an RFP, terms such as ‘will’, ‘shall’ and ‘must’ are all interpreted the same way – as something that is mandatory. So a requirement that is worded as ‘The system shall….’ would become a mandatory capability in an RFP just by containing the word ‘shall’. Requirements are best stated in terms of capabilities, avoiding use of terms with vested meanings.

With these considerations in mind, requirements can be phrased and organized in a way that best facilitates comparison and evaluation of the different solutions that are proposed in response. Mandatory requirements can only be scored as either a pass or fail. Requirements put forward in an RFP as desirable instead can be given relative scores and weights, allowing different solutions to be compared for best fit across the total set of requirements. Requirements can be grouped and minimum scores can be set in different functional categories as desired, to separate well-rounded solutions from those that score very highly in some areas but very weakly in others.

--
Sandy Lambert
Business Architect
LinkedIn Profile

RATE THIS TOPIC

12345

ADDITIONAL ANSWERS / COMMENTS

Robin Goldsmith posted on Saturday, February 8, 2014 11:58 AM

Sandy, thank you for giving an unusually correct description of how requirements should be described for an acquisition. Building on my experience with more than 20 acquisitions in all capacities and observation of many more, I developed and presented the first and to the best of my knowledge for many years only course on software acquisition in the world. Most acquisitions fail because (1) the acquirer did not identify what you’ve described and which I call their REAL business requirements deliverable _whats_ that provide value when met , and (2) they instead specified features/requirements of a presumed product/system/software which more often than not turned out not to be what they needed and unnecessarily constrained their vendors, thereby depriving them of their vendors’ expertise in designing and developing applicable systems.

However, I’ll differ with your answer in that the same REAL business requirements need to be defined for projects that develop a custom system.

Sandy posted on Friday, February 14, 2014 10:25 AM

Robin,
Thanks for the feedback - and kudos for developing and presenting a course on acquistion.

My rationale in differentiating between requirements for acquistion vs. custom build is based on a number of factors:
- Terminology: As in my post, a requirement worded as 'The system shall' is valid and acceptable practice for custom build, but doesn't work well for acquisition, particularly in a formal procurement through RFP.
- Format and organization: Common requirements documents such as use cases can work well for custom build, but don't work well in RFPs or equivalent acquisition documents. Vendors struggle with responses to requirements put forward in use cases, and evaluation teams struggle to interpret those responses. So the format and organization is usually different in acquisition vs. custom.

As to level of detail, I have tried to avoid that in this interview question. It is a best practice to use a fairly high level of detail in acquisitions, as supported by industry leaders such as Gartner Group. Whether more detail or less detail is needed for custom builds is likely a subject of much debate. I'd much rather see this particular topic posted in a blog or forum post, where we could have more open discussion and debate than an interview question.

Thanks again for sharing your thoughts, Robin. I would encourage you to keep contributing on ModernAnalyst - whether in responses to interview questions or on the forum. Feel free to connect with me directly on LinkedIn as well.

Sandy

Robin Goldsmith posted on Friday, February 14, 2014 11:41 AM

@Sandy, I appreciate your thinking requirements should differ for acquisition vs. custom build. The mistaken basis for such thinking is one of the main traps that cause most development to fail. It’s not that ‘system shall’ and use cases requirements are wrong, only that they are not the full story. They are forms of requirements for the product/system/software _how_ which is presumed to be needed but which provides value if and only if it satisfies the REAL business requirements deliverable _whats_ that provide value when met.

Effective acquisition recognizes that the vendor’s design of said product/system/software is a key part of the value acquisition provides, which is why the RFP should identify the REAL business requirements and not presume to impose a product/system/software design (unless truly the only thing being acquired is coding of said design, which is a whole different issue). Unfortunately, people somehow mistakenly think they can skip the _whats_ and go right to the product _hows_ when doing custom development, whether internal or external.

The same REAL business requirements deliverable _whats_ are needed for each situation. Moreover, in both situations they need to be driven down to detail; and no matter how far down in detail they are driven, they always remain business deliverable _whats_ that provide value when satisfied by a product/system/software _how_. Contrary to the widely-accepted but still mistaken levels model of requirements, REAL business requirements _whats_ are not just high-level and driving them down to detail does not decompose them into product/system/software requirements _hows_.

You can read more about these important distinctions in my book, Discovering REAL Business Requirements for Software Project Success, and in my Modern Analyst featured articles, such as ‘BAs Will Falter Until They Learn to Discover REAL, Business Requirements’ at http://www.modernanalyst.com/Resources/Articles/tabid/115/ArticleType/ArticleView/ArticleID/1193/Default.aspx.

Sandy posted on Friday, February 14, 2014 12:31 PM

I definitely appreciate your perspective.

My perspective is different, perhaps because I'm operating from a different paradigm. I've seen great success myself with the tools and techniques that I use, my company has seen great success on projects of all shapes and sizes, and I continue to see demonstrable success in the industry - including the experiences shared by BAs on this site, in my peer networks, and in the great work done by organizations such as the IIBA.

So my experience has not been that BAs are faltering. And while I certainly have seen projects that weren't as successful as they could have been, it's not usually the BA methodology itself that is the root cause of those failures. There are a lot of contributors to project success or failure. And there is still 'art' as well as 'science' in the BA profession in terms of individual BA skills and expertise. But while the BA profession continues to grow and improve, they're still doing a lot of things right already.

Robin Goldsmith posted on Friday, February 14, 2014 1:15 PM

@Sandy, I’m delighted to hear you are having such good results. I suspect it’s because you’re doing a lot of what I’m talking about, probably albeit somewhat unconsciously and implicitly. However, I don’t think one can generalize your own successful implicit skills and practices to others. Even recognizing the likely methodological issues (I’ve written about elsewhere), the Standish Group’s CHAOS reports and numerous other informal sources continue to describe reasonably accurately an industry where most IT projects are late, over budget, and still not providing needed functionality.

There also seems to be widespread agreement that inadequately-defined requirements are the main cause of such project problems. Since business analysis is the role responsible for defining requirements, I don’t think it is unreasonable to characterize business analysis as faltering. I contend that a major reason results remain much the same is because the business analysis industry keeps following mistaken models and never truly addresses the real underlying causes. I also appreciate that this turns into a logic quandary similar to where Congress has a 10% approval rating and yet a 90+% re-election rate.

Only registered users may post comments.

Do your homework prior to the business analysis interview!

Having an idea of the type of questions you might be asked during a business analyst interview will not only give you confidence but it will also help you to formulate your thoughts and to be better prepared to answer the interview questions you might get during the interview for a business analyst position. Of course, just memorizing a list of business analyst interview questions will not make you a great business analyst but it might just help you get that next job.