views:

41

answers:

2

As with most developers, struggling with poor, vague, incomplete, and not thought out requirements. I know most people feel developers should pull double-duty and help with business analysis, but if you have large number of individual projects, it's hard to be a 'business subject matter expert' for all of them.

So, here is my question - is there a good collection of processes related to developing requirements (requirement life cycle)? Specifically functional, business requirements that a person writing code would need from someone in the line of business/sme/business analysis (example: I want to be able to add another type of member to the system, including driver license requirements and date of birth....which would lead to the next questions of does u.s. state driver license ok, is state id ok versus driver license, does date of birth have certain constraints (i.e. state id for someone under 18 ok, or if senior age relevant), etc).

Requirements Development life Cycle along the lines of -

Idea -> Brainstorming -> High level requirement.

High level requirement broken up into detailed business requirements and technical (non-functional) requirements.

Requirements analysis to compare detailed requirements against existing requirements already in place (if existing system), compared against each requirement to other requirements to ensure non-contradictory, best-effort to ensure requirement is not vague or missing critical details and is as non-ambiguous as possible.

prioritization of requirements, categorization and collection of requirements into deliverable/milestone sets (i.e. these 6 requirements should be completed together, while another 11 should be completed together but at a later stage).

post-implementation, testing the implementation against the requirements and tools/processes/measurement to identify areas to improve on the Requirement Development Lifecycle.


ok, I'm starting to rant a bit, so stopping -- question is, does there exist something that focuses on maturing the requirements process?

-->domain expert/sme who has knowledge (tacit knowledge?), but has very little time or desire to document expectations. In this case, the domain expert/SME acts as the customer, as the customer themselves are looking to the company to solve their business problems in an efficient and quality manner.

-->developer who has skill to help solve problem, but no idea on 'devil in the detail' issues around the problem, or even what 'efficient' or 'quality' represents for that domain.

-->manager who has some resources, but not unlimited resources, wants to make the customer happy.

A: 

There are many ways how to go about requirements, but there is no definite process. Every big methodology tackles with requirements, look for example at Unified Process. It is not easy to be formal about requirements, formal specifications are quite expensive and semi-formal methods give no proofs. It is common practice to use Use Cases for object oriented systems, more recently in agile there are User Stories. I suggest looking at some methodologies or books on requirements engineering.

Gabriel Ščerbák
+1  A: 

As @Gabriel says there are many ways of going about this. Requirements management is a speciality in itself. It has largely been developed in connection with safety critical systems; in connection with very large projects; in connection with military projects; in projects that have to (for legislative or regulatory reasons) conform to defined standards; or in connection with projects that have large numbers of stake-holders. These all share the same characteristics - multiple requirements that need to be reconciled; may be contradictory; need analysis and categorisation; and need integration before they can be put into a form that is testable, consistent and gives rise to a coherent, prioritised set of software requirements that can form a suitable system specification.

Other specialities are testing, test planning, quality assurance and continuous improvement.

Having said this there are a number of books and resources that can provide a start into consideration of these topics:

Books:
  Object Orientation: The Kiss Method - Kirsten
  Problem Frames. Analyzing and structuring software development problems - Jackson
  Objects, Components and Frameworks with UML - D'Sourza; Wills
Methods/Consultancy
  Volere
  Shlaer-Mellor
  Kennedy-Carter

The Unified Process referred to by @Gabriel was (I think) originally Introduction to the Personal Software Process. This is a good small scale start.

Use cases and User Stories do have their place, but I would be wary of anything that put these forward as a primary tool for requirements management. They do have their place, but also have some substantial problems and limitations, which are often not brought out when promoting their use. Also I would tend to regard these as outputs from requirements management rather than as a major aid to analysing requirements.

Chris Walton
I omitted one book reference. In giving a clear picture of what requirements need to be he does imply a lot about the process of requirements management. This is: Practical Software Requirements: Kovitz
Chris Walton