Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In an agile project -

  1. I assume user requirements are captured in terms of user story. Is this correct?
  2. How are system requirements encompassing all the constituent applications documented (in case of a large project)?
  3. Are there any specific tools used?
  4. Is it a good idea to capture system requirements as child user stories under a main user story?
  5. Should individual component teams produce SRS document containing requirements specific to the component team?
  6. Should there be a low level design document or will it be part of SRS document?
share|improve this question

closed as not a real question by Telastyn, Eric King, MichaelT, Martijn Pieters, Frank Shearar Feb 12 '13 at 18:44

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

For close voters: This question is a very good one, for anyone trying to learn industry standards. I can remember how I "ate" my lecturers heads asking these questions. This question might be not a "real question" for you, but this is a "real question" for lot out there. Throwing someone's question out just because it doesn't fit for "you" is not democracy. – PeakGen Feb 12 '13 at 18:52
Thanks a lot , Sepala :) – Punter Vicky Feb 12 '13 at 19:12
I'm guessing that the closure is due to this section of the FAQ - questions should not be overly broad (there should be a concrete answer, not 6), and should be answerable in context of a few paragraphs at most - not an entire book. – GalacticCowboy Feb 12 '13 at 20:56
up vote 3 down vote accepted

User Stories capture the need of a user to be able to do something, the details of which will be elaborated on during the iteration in which a team takes on that story. That is, a User Story is the basis for a discussion--it is not "Requirements" as such.

So, system requirements should come up in that discussion that occurs during the iteration.

Note that using User Stories do not preclude writing down system (or other) requirements as they are known. These can aid in the discussion when it happens, and keep folks from forgetting them. These should NOT be treated as "signed off" requirements in the traditional sense though--they may change due to the discussion. They should be used simply to aid memory and communication.

As I always do, I'll recommend Mike Cohn's User Stories Applied to anyone new to User Stories.

share|improve this answer
  1. "User story" is not the exact word I guess. That part is requirement engineering. There are lot of ways of gathering user data, such as interviews, questions, work at client's place etc.

  2. Agile keeps less documents. What you ask is completely "company based" or "developer based". In some places, there are people who track all the work and provide these docs at the very end, just like a director editing a movie.

  3. I don't know about specialized tools for agile. But yes, tools for version tracking, development and testing are used.

  4. Your question is not clear

  5. Every team maintains their own docs. These require to be passed to QA people. Agile docs may be not 100% quality. Lot of editings, patches might be there.

  6. What did you mean by "low level design docs" ?

share|improve this answer
Thanks Sepala. With respect to qn. 4 , tools like rally help in capturing user story. It also allows child user stories to be created for a main user story. I was checking if the system requirements / user requirements can be documented as child user story. – Punter Vicky Feb 12 '13 at 18:39
@PunterVicky: OK. I am sorry your question is closed :(. I posted a comment against it anyway – PeakGen Feb 12 '13 at 18:52
I mean, against the close action – PeakGen Feb 12 '13 at 19:01

The whole point of "agile" is to cut down on things that don't matter. The only documentation that is created is what is absolutely needed. Unless a project explicitly requires documentation as a deliverable, it only exists as long as it is useful - you don't collect mountains of requirement documents.

share|improve this answer
Thanks a lot Sean – Punter Vicky Feb 12 '13 at 18:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.