Where do requirements end and design begin?

Question

I imagine this question has been asked in various forms previously but I couldn't locate a specific answer after searching around.

I am currently working in an independent oversight role on an outsourced software development project. The team and vendor are currently working through the functional requirements specification and trying to elaborate and clarify the requirements. As I sit in these meetings, I am noticing that the discussions very easily fall into what sounds like "solutioning." In other words, people are starting to draft the requirements in such a way that presupposes a correct solution to the business problem.

My question is, when are these discussions appropriate? As a business analyst I am naturally inclined to avoid jumping to conclusions about the solution until design begins and the needs are fully flushed out but is any of this appropriate towards the latter end of writing the functional requirements? This has always been somewhat of a gray area for me. Any help would be appreciated, thanks!

Answer 1

This question is a perfect example describing one of the root problem and why many companies liking & switching to Agile Development.

If you are familiar with some agile development concepts you will understand my response as is. If not try to read about scrum, product backlog, definition of done, user stories, retrospective, sprint review etc..

I would ask why requirements have to end to start the design? this about it: If we retrospect our own past experience we can say that requirements are changing element of the sw development process and hence design/development as well. What generally happen is Product owner/manager start discussing requirements and soon developer start asking questions/clarification very soon develeopers/technical person in the room starts thinking about design/development. rather focusing on what&why everyone starts thinking on how.

So here is my quick suggestion.

ask product owner to start the discussion with the sentence like this:

I want to do<what> so that I can do <why>

for example

I want to <create some default users created in the system> so users can <login to the system using their own user credentials>.

now everyone in the room needs to start thinking about this what and why only and think about the questions related to what&why only. for example, why we want default users to ship in the system? isn't security a concern? Is creating user runtime a difficult process? who will be those default users are? what type of permissions should be given to this default users? what should be the default password to those users? what should be the expiry on password? who will communicate the default user/pass to those users?

These questions give audience ability to understand the actual usefulness of the feature the product owner is asking to implement and also everyone in the room will stay on the same page to understand the whole feature and how it supposed to be used. Try to stick to the end to end user workflow and understand the business need/value of the feature. this type of conversations I would expect during product backlog sessions.

Once the team understands 60-75% of "what&why" the feature is ready for the estimation. At this time if team members estimate are way off from one another one or more member can explain the whole room what was his/her thinking behind that estimate and this will lead into somewhat design/implementation discussion. again this design explanation and discussion need to be time boxed and keep it very high level so that everyone just become comfortable with the solution as by the time team actually start working on the feature some requirements may have changed.

there are more good things beyond this explanation and I am happy to be volunteer or guide if you need more details. let me know if this information is helpful and you think that this is something you might want to try for your team.

Answer 2

Your problem has more than one aspect, which is also why you basically have two questions in your post:

Where do requirements end and design begin?

and

When are these discussions appropriate?

I'll address these questions separately:

Where do requirements end and design begin?

Taken literally, the answer to this question is question is: Requirements don't end when design begins. Once you have completed your initial requirements, it is highly likely that they will change, so you need to implement a change process (e.g. a change review board in classical project managment or maintenance of the product backlog in SCRUM). Also, when your product design is completed, you need to verify it against the requirements.

I understand your question though in the sense of "When do inital requirements end?". The answer is: It depends on your project approach. If you are using a classical approach like waterfall or the V-model, the answer is: once the requirements specification is completed. If you are using an agile approach (such as XP or SCRUM), requirements and design run in parallel. You are preparing the requirements for the next iteration while the developers implement the current requirements.

When are these discussions appropriate?

I admit that the first part of the answer is a bit technical, and I can see that youir real problem lies in the way requirements are drafted. To answer the question, it depends on which requirements you are working on:

1. The high-level business requirements.
2. The lower level application requirements.

If you are working on the business requirements, you want less technical aspects than when working on the application requirements. The reason is quite simple: the higher your requirements level is, the further you are away from the implementation and the less these things matter.

In practice I have rarely seen this kind of distinction; you usually talk about "the requirements". And how much design details you want in your requirements depends on a number of factors, for example:

1. What kind of system are your building? When you build an operating system, you can not craft the requiremenst without a lot of technical details.
2. Company culture. A tech company will see the definition of what is a requirement differently than a retail company.
3. The project team. Developers see requiremens differently than business analysts and depending on your team composition there will be different outputs.

Especially in lower-level requirements, technical details are not always a bad thing. For example:

• If a requirement says that the designed webpage should use responsive webdesign, it is probably OK. Although this is a technical term, it describes very well what is desired as an output.
• On the other hand, purely technical details like choice of programming language don't belong into requirements.

To disagree on what is requirement and what is implementation detail is quite common. I though have made the opposite experience: product managers often try to limit the definitin on "what is a requirement" to offload the detail work to the development team (let's face it: requirements are hard).

The best answer I can give you is: Address your issue openly with the team. Whether you are the only one seeing matters like this or others agree with you, you have a valid point. You should figure out some guidelines on what is a requirement (you can also write them down for reference), so that everyone is on the same page. If your team works well, you won't need any moderation, since you will be able to work it out together. Since there is a grey area, you will find a solution that probably everyone will be able to live with. If you have some friction in your team, you should nominate a moderator that everyone accepts as neutral. Or even better: try to work out your friction, since that will benefit the project in other aspects, too.

You should also make sure to include the members of your team who will use the requirements specification (developers, testers etc.) in your discussion. They will have to work with the specification, so their point of view matters. What would also be benefitial is to review the requirements document including (but not only) these stakeholders. The review serves as a corrective in case the requirements err too much into the technical implementation.

Once you have clearly defined what is a requirement, you should be able to draft a requirements document everyone is happy with. A review will correct any issues that remain.

Answer 3

It depends on who is in the room.

Ideally, you should have a set of requirements that you develop that are complete statements about functionality with no reference to technical implementation, tools used, etc. Requirements are supposed to be like a blueprint from an architect that can be implemented differently (using slightly different materials and tools) by different builders. In reality, things are not so cut and dried.

There can be cases where requirements and design feed into one another. In fact, that inevitable likelihood is why we try to do iterative testing, prototyping, and make fun stuff like clickable wireframes for customers to play with. It is VERY common for the customer to not completely realize what they ACTUALLY need until they have something resembling real software to interact with. Design, by nature, will delineate what CAN be done (within reasonable cost/time limits) using the technology stack and tools chosen. Design, therefore, leads to some logical "This could be done easily with what we have, do they want this?" Kinds of conversations. That circular feedback between requirements, design, and back to the customer really continues for the entire life of the product. That's why we talk about a SDLC (Software Development Life Cycle).

I am a business analyst and I have had requirements elicitation sessions where I asked my team Tech Lead to sit in with us because of his expertise with the existing functionality of the application, and I knew that would be very valuable to the customer as they worked out what, exactly, they were asking for.

In general, when you get a few knowledgeable engineers in a room, you are going to get some talk about implementation details. That's almost always a good thing, and I always pay close attention to that kind of architectural discussion because it does help me break out functionality into logical slices that can be potentially built in one development sprint. I personally think that architecture knowledge is always a plus for a business analyst. What you want to do (in my opinion) is keep the initial stages of elicitation focused on the customer, not the software devs. What does the customer do now? What do they think they want to do? What do they really need to do? The early stages are about understanding their business processes, which are the VERY heart of delivering VALUE, not just delivering code. Clearly, early stages of requirements elicitation should avoid talk about implementation for a lot of good reasons.

At some point, you will have passed a threshold where requirements HAVE been formalized but you are not complete, engineers HAVE sat down and started working through them and you (as a team) have a good idea of how you are going to approach the project. You may still be having requirements sessions, but as the design phase progresses, it will logically overtake requirements gathering. This is not necessarily a bad thing, but you have to maintain a clean requirements document ("document" used loosely: it totally depends on how you are organized) that allows you to maintain requirements traceability. If you need to kick the engineers out of the room a couple times to get that, then go ahead.

Having a clear requirements document is important for testing, which is critical for modern enterprise application development practices. This should be clear of implementation details, but it can certainly use feedback gained from the understanding of what can be done with a given set of tools.

In other words, it's not totally clear cut that implementation talk is necessarily out of place in a requirements session, but best practice is always to write requirements such that they are "implementation neutral". My rule of thumb is to not stand on formal procedure too much if we are collaborating well with the customer and a lot is being accomplished, so long as we DO have a good understanding of where we are supposed to be going.

Answer 4

In order to avoid over-specifying, and to write down the real needs of the customer, you can employ the following strategy:

start/convert every requirement with "the system shall have the capability to..."

This strategy disallows the customer to enter the realm of design inadvertently. (I've read this approach in a book about systems engineering, will cite the reference if I can find).

However; I believe the customer may dictate (fairly) some design solutions if or when:

1) the customer needs to define a use case (for example: user enters data using a touchscreen with his bare fingers)

2) there is some interface to some existing system

3) the design is partly defined and the customer wants to make sure it stays as is

4) the customer wants to reuse some existing hardware/software as part of the solution.

I've seen several contracts, some over specifying and some broadly defining, and the conclusion is as long as the parties are happy, the specs are sufficient. Although technically speaking, many are far from ideal.

Lastly, the design team's best argument against over specifying is: you may forget some topics ("completeness") and may result in a non working system (conflicting requirements), which may cause iterating a contract/schedule slip/cost.

Answer 5

There are three levels of requirements:

1. Business Requirements (why we need a system).
2. User requirements to software (what users need to be able to do to enable Business Requirements).
3. Functional/nonfunctional Requirements to software (what developers have to implement to enable User Requirements).

Only the first level relates to a business project. The second and the third levels relate to IT projects and distinctly contain the phrase "to software". So Business Requirements should define a business problem and possible resolving ways like purchase of licenses of some existing product or develop software by yourself or to buy a company that owns that beautiful software etc.

Business Requirements are usually defined in a Vision and Scope Document (contains business opportunity, business objectives, business success metrics, business risks, limitations, scope etc.). Other names of this document: business case, project charter, market opportunity etc.

Software design starts from User Requirements to software because users start by imagining what they want to be able to do. Of course your designers/architects have to review requirements constantly. It is an example of continuous integration of any information in a project - no one should be surprised by the results of predecessors.