How much effort should be assigned to requirement specification within a project? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts 开发者_C百科and citations by editing this post.

Closed 3 years ago.

Improve this question

Assuming the global development effort is known (from a preliminary work structure breakdown), what percentage of that effort should I add in order to allocate enough manpower for requirement definition and refinement?

---

Requirement definition should be just that. In my experience people tend to envision the future solution already and start to put design assumptions into the requirement specifications. This unnecessarily prolongs the phase with lots of workshops and discussions. If you keep it strict to pure functional and non-functional requirement gathering (not design) I would put no more than 10%-15% of the time into it and no more than 10% of manpower effort. In your situation it seems like there are certain design descission already made and agreed to. However I would still see 10-15% because having the requirements formally put down and signed off are of good value in the project being referred back to all along the way. I once took over a project where all the personal for later phases was already recruited and burned down costs so I had to live with it. In that case I had to assume more effort (but not time) for that phase because I just did not want to skip it or skimp the phase and had the high burn rate as a fact. In project management sometimes external conditions ask for alot of flexibility and seldom all is perfect. It is also not seldom that you get assigned a certain budget as a share from a global budget and have to live with it. Often the milestones are also set. Like "do it in one year". So time is 10-15%. Effort should be less.

---

Read this: (Sorry for the short answer, but you asked a vague question)

Software Estimation: Demystifying the Black Art

---

Depends on the complexity of the problem domain, the number of stakeholders, their level of agreement, the familiarity of your requirements engineers with the problem domain, your company culture, your development model (how much is enough to get started).

More than 0%, less than 100%.

---

Use an 'iterative' development approach for software, that is continually revisit the requirements in light of discovery during conversations about design and implementation. Involve the 'customers', that is the people who produced and own the requirements, at all stages of production (using prototypes if possible). Also use short delivery cycles so that if there is a misunderstanding the gap is identified quickly (rather than in six months for longer water fall based projects). Follow this type of approach and the requirement process will take as long as needed, during the iterations, and future sprints to clean up misunderstandings.