需求和技术设计是单方面的努力？

Question

I've been working on a large, multi-year project as a web architect.

So far, my responsibility has been to take requirements documentation provided by the customer's analyst and translate them into technical design documentation.

The 'powers that be' suggest that I take over the requirements documentation and combine them with my efforts on technical design.

Is there a specific problem you see with combining requirements and technical design into one step?

Note that we are already well into development, so a lot of the technical choices (os, app framework, database, servers, etc) have already been set in stone.

Answer 1

"Is there a specific problem you see with combining requirements and technical design into one step?"

Yes.

Requirements have almost nothing to do with technical design.

Requirements define "what" must happen. Design explains "how" it will be built to make that happen.

For instance, I want a beer -- that's my requirement.

Technical design could be

1. Get off my chair and walk downstairs. Low cost. There's a risk here. There may be no beer.

2. Get off my chair and walk to the pub. Higher cost. There's little risk here. Except Sundays when it's closed.

3. Ask my wife. Huge risk here. Possible unintended consequences. However, I've delegated the problem and she now has to either find beer in the house, run to the store, or tell me to get my own. If she's going out anyway, we're back to low cost and no risk.

One requirement. Multiple designs for solutions. You can't work on both things in one step.

You must document requirements (actors, use cases, conceptual data model, conceptual processing model)

You must then design a solution. The solution may -- or may not -- involve creating new software.

When studying requirements you often find situations where the users need to change the way they work. Requirements can be met a number of ways.

One person can both document the requirements and do the design. But you must do them separately. You must document the requirements in a way that they users understand and agree to the nature of the problem and what's required to declare the problem solved.

Then -- separately -- you decide how best to optimize cost, risk, time-to-deliver, skills, available technology to offer some solutions to the problem.

Answer 2

If you're "well into development," I would hope that the majority of the requirements are pretty firmed up. I don't argue that requirements need be set in stone before development begins (heaven forbid), but I'd hope it'd be pretty certain what kind of thing you're building by this point. So if the point by now is just "requirements documentation" (rather than really digging into what the customer is looking for), I can't see any deep problem here.

While there is a certain advantage to separating development from a "customer advocacy" role, a professional developer shouldn't have trouble keeping track of requirements without generating any conflicts of interest. Is there some other issue you were concerned about? Is requirements documentation even a large task at this point? Reducing the number of layers between the customer and the developer actually sounds like a pretty good thing.

Answer 3

Yes. Combining requirements and technical design clouds your thinking -- it prevents you from later coming up with new ideas about how to improve the system by doing a different technical approach/optimization.

Especially in new technology areas, you may very well start off with the wrong approach. Combining the technical design and requirements induces you to think of your technnical approach as a requirement, when it could very well be scrapped and done differently.

Also, when it comes time to test (actually that time should be before design) then you may be testing your technical approach rather than what the porgram actually needs to do.

Answer 4

I think there's great value in having requirements and design done by the same people.

If you're getting requirements, you'll actually be talking to the business. It'll give you a chance to learn the business and hear what they really need, unvarnished and unfiltered. You'll have a chance to persuade them to talk about the problem in business terms instead of assuming a technical solution and jumping right to design (eg, "Add this column to this table and tie it to this text box on this page.") Maybe you'll be able to see ways of attacking a problem that they didn't even know existed.

Answer 5

I do not have the opportunity to work in an agile team or scrum team, nor have I have the chance to apply them. I do a lot of one-off development work for customers for 1~3 months. But one thing that I have learnt when in this kind of environment is:

Sign off with the customer every stage of the project.

Which will answer your question as: Never mix requirements with design document.

Actually, it goes beyond that.

1. First off, sign off the Scope of Work (SoW).
2. Then, sign off the Requirements.

We have, in many times, seen unreasonable customers, who have ever changing requirements. However, they do not expect to pay for these changes. If not managed properly, project cost will greatly outweigh and exceed the project income.

Having a signed-off SoW protects you from out-of-scope requirements, eg. "the vendor will install app xxx", and all of a sudden, "the client wants an entire PKI infrastructure installed to protect communication to app xxx".

Having a signed-off requirements protects you from sudden and unreasonable requirements, following a similar case from above, "there is no need to protect and encrypt communication to app xxx".

Note that these are legal protection. It is still up to you to decide if a new requirement from the client should be done. It is still good however to stress that they are not in the requirements and are purely done out of good will.

Merging the design document into the main requirements document prevent you from signing off the requirements document. The customer will be extremely happy about this, but I think your development team will hate the possible crunch time.

I did see an alternative approach people have (but not on merging design with requirements).

Split up the requirements document into a main file with seperate appendix files. Keep important and concrete things in the requirements document. This allows you to sign off the requirements document, while allowing changes to the appendix be done at a later stage. We mostly use this approach for support documents as the appendix. It might work with design doc as an appendix, but I have not seen a design doc as an appendix.

Besides, in some projects, you might even want to sign off design doc before development starts. Or these design/requirements/SoW are delivery or milestone payment.

Really, try to avoid merging them.

Answer 6

Requirements refer to what needs to be done. Technical design refers to how the requirements can be fulfilled.

Disadvantages:

• One disadvantage of combining them is that, if you're a technical guy, you'll try to influence the requirements to make the technical task easier, focusing on how . In the end, you might develop a system that doesn't actually address (all) the problems of the user(s) of that system .
• Another disadvantage is that, while clarifying the requirements, the technical solution will need to be adapted to fulfill the new features/details that were clarified or discovered during requirements elicitation. That means modifying/rethinking the technical solution several times during requirements clarification .

Possible advantage:

• Having an overview of the technical solution while discussing the requirements, you might "bend" or negotiate the requirements in order to avoid later discovery of technical issues (eg performance problems, unfeasible or costly features with added value not proportional with the cost of implementing them). But you have to be careful not to invest too much on the technical design before the requirements are really clarified.

Answer 7

Another difference in the two is that requirements development requires extensive contact with the client (external or internal client) and many good technical people simply don't have the people skills to manage client relationships well or to talk to actaul users without insulting them. Only you can say if you do. You will find it is much harder and more complicated than you think if you haven't been doing it. Plus you may find yourself asking the wrong questions because you are failing to see the viewpoint of the user since your expertise is in the viewpoint of the developer and designer.

Personally I also find that having multiple people involved in the design process (gather requirements and translate them into a design) is helpful in terms of idea generating and in terms of thinking of things the other person may have missed. Moving from two people doing this to one may not a good idea from the standpoint of team synergy. When the same person does both, it is easy to do things in only the way you are used to and there is no one else involved to challenge your assumptions until you are much farther along the path where it becomes more difficult to change.