• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Whose responsibility are Requirements Specifications?

 
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

It's always funny in Germany to talk to people and ask them about Requirements Specification stuff. I think not only in Germany but everywhere that the term Requirements Specification is overloaded. Hence there is time to time a struggle what is meant by it really.

For example, what do you think means System Requirements Specifiation and Software Requirements Specification and who is responsible for producing these specs?

And for all german speakers, how would you translate the german terms Lastenheft and Pflichtenheft?

Regards,
Darya
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Darya Akbari:
I think not only in Germany but everywhere that the term Requirements Specification is overloaded. Hence there is time to time a struggle what is meant by it really. [...] For example, what do you think means System Requirements Specifiation and Software Requirements Specification and who is responsible for producing these specs?



I could try and generalize what people seem to use this term for as being "the product definition", i.e. a description of what I, the one paying you to build the product, consider important properties, attributes, and constraints the product should have or conform to.
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Lasse Koskela:
I could try and generalize what people seem to use this term for as being "the product definition", i.e. a description of what I, the one paying you to build the product, consider important properties, attributes, and constraints the product should have or conform to.



Well, these seems to me all issues that belong to the Requirements Specification coming from the customer.

Now which Requirements Specification is the one the customer give us? Isn't it the System Requirements Specification, the one a customer provides to me when she makes a Request for Proposal (RFP)?

How do we call the Requirements Specification that we provide then as a reaction to RFP to the customer, which will become part of the contract between me and the customer? Isn't that what is called the Software Requirements Specification?

Regards,
Darya
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you are interested in bringing the project to success (instead of covering your a1s), I don't think it makes much sense to define once and for all who should be responsible for which requirements specification. Of course the customer should have the final say on what he needs, but you will want to have everyone from the team contribute to the project what he can. So I'd think that the whole team needs to decide how to best collaborate on the specifications to get the best result, based on their specific situation and skills.

Does that sound reasonable?
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let me try it this way. The Requirements Analysis Phase is something which is done on the customer side before there is any chance that one of us can get on board.

I know we could do the Requirements Analysis for a customer too. I even saw that a customer let do Requirments Analysis by one company and give the project to another company . But what is the deliverable of that Requirement Analysis? Isn't it that System Requirements Specification? I mean after the customer approved everything it is this document which leaves the customer and gives us a first insight of WHAT the customer needs.

In the next phase we take this WHAT document and provide our HOW document, the Software Requirements Specification.

What I've seen so far, both documents are called Requirements Specification but with totally different meaning.

Regards,
Darya
[ April 28, 2007: Message edited by: Darya Akbari ]
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Darya Akbari:
how would you translate the german terms Lastenheft and Pflichtenheft?



Keep in mind that there are projects that aren't about software development. DIN 69905/PMBOK try to cover all kinds of projects.

Lastenheft - Statement of Work (as issued by the Customer) http://www.kbs.uni-hannover.de/Lehre/SWTG/S06.pdf
Plichtenheft - Proposal (as issued by the Vendor) http://www.kbs.uni-hannover.de/Lehre/SWTG/S08.pdf
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Darya Akbari:
In the next phase we take this WHAT document and provide our HOW document, the Software Requirements Specification



I think you are getting a bit bogged down by trying to differentiate terms that are sometimes used interchangeably (I've often found that English word/term use is much less precise than what you might be used to in German). If I had to choose a (document heavy) definition for the requirements I would go with the "IEEE 830-1998 Recommended Practice for Software Requirements Specifications (ANSI/IEEE)". From the SRS you would then develop more documents such as the �Functional Specifications� and the �Non-Functional Specifications� (note that the word "requirements" doesn't appear in any of these terms - yet if you look around, you will find somebody writing about "Functional Requirement Specifications" and the "Non-Functional Requirement Specifications" :roll: _).

So as far as I am concerned the SRS is the WHAT document and the functional and non-functional specifications are the HOW documents.
[ April 26, 2007: Message edited by: Peer Reynders ]
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Everybody's WHAT is somebody else's HOW. Say you're told what to do and you have freedom to decide how. You make up a strategy and some steps and hand it to the next guy. Now you're telling him what to do and letting him figure out how. He breaks it down into some neat steps and tells some cube slaves what to do. They figure out how and write some code that tells the compiler what to do. The compiler figures out how and gives some bytecode to the JVM. The JVM figures out how ... it never ends, right down to the quarks and bosons tunneling through semi-insulators.

So, requirements are not Carved In Stone, REQUIRED to keep the earth turning. They are somebody's decision about how to solve a problem. Just as there are many levels of people setting direction, making policy, thinking up strategies, etc. there are many levels of requirements docs. And no universally accepted names for them. So what's an SRS to you may be somethign totally different to me. Bummer.

I used to do a couple levels of docs; one that describes how a computer system will help get somebody's task done without mentioning screens, buttons, menus, widgets, and another that describes screens, buttons and so on. Both were usually collaborative with the customer, Goal Donor or Gold Owner. What was missing was the doc above these that tells us why we're doing all this. Sometimes we get enough of that from conversations to suggest an alternate HOW at that level. Then a requirement is replaced by a new one. Heh, wasn't really REQUIRED was it?

Long and mayabe useless answer, but this is such a fuzzy business. All the teams I know struggle with it, and the company's direction is to add more layers of people and docs and handoffs, which seems ... can't think of a nicer word right now ... wrong.
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Having done a fair number of projects both in English-speaking countries and German-speaking countries, I'd have to concur that it's rare for these documents and roles to be prepared and adhered to with this much precision.

I think Ilja sums it up very well - to some projects these terms apply, to some they don't, but the important thing is not the documents, it's the outcome for the stakeholders (to tie this to another thread of yours ), especially the customer. Sometimes the customer won't even produce a requirements document, sometimes the customer will even do the technical specification. Well, the customer's paying, so what's to stop him? Whether the execution of the project actually follows this path is a different matter.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Darya Akbari:
Let me try it this way. The Requirements Analysis Phase is something which is done on the customer side before there is any chance that one of us can get on board.



I think this is a very limiting view, in two aspects:

First, the reason to introduce a software system is to change the process it will be used in. Most often, the customer doesn't have as much experience as the software provider to assess the impact of the introduction. Not making use of the experience of the software provider from the very beginning will then be suboptimal.

Second, every situation is different, and even the most experienced analyst is unlikely to be able to anticipate all the effects and needs accompanied with the introduction of a new/changed software system. As a consquence, analysis needs to be an ongoing activity throughout the whole project - declaring it "done" before you start coding will ignore so much valuable feedback from actually implementing and using the system that it significantly reduces the project's chance of success.
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are some interesting points here in this discussion. I'll get back to it at the weekend.

Regards,
Darya
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

first of all, thank you guys for this discussion .

I like the definitions from PMBOK. Peer I'm glad that your german roots do help here .

Originally posted by Peer Reynders:
DIN 69905/PMBOK
Lastenheft - Statement of Work (as issued by the Customer)
Plichtenheft - Proposal (as issued by the Vendor)




On the other hand IEEE, as Peer hints, has its own definition of this stuff.

Originally posted by Peer Reynders:
I would go with the "IEEE 830-1998 Recommended Practice for Software Requirements Specifications (ANSI/IEEE)".
...
So as far as I am concerned the SRS is the WHAT document and the functional and non-functional specifications are the HOW documents.



So this can be one origin why we have those naming conflicts. Despite of that, I don't think SRS is what you mean . The central word here is Software. To me Software is the HOW and System is the WHAT.

See my reason why I see it this way:

Like PMBOK from PMI we have SWEBOK from IEEE. The Software Engineering Body of Knowledge (SWEBOK) from IEEE states that it is based on PMBOK and that it add Software Engineering aspects to PMBOK. In this sense IEEE's SWEBOK added the terms System Requirements Specification and Software Requirements Specification to the discussion.

These terms are not my invention. They were brought in by IEEE. In Germany we have a similar Standardization Body like IEEE called DIN. I often tend to those standardization bodies when there is confusion about words and their meaning like here right now.

Originally posted by Ulf Dittmer:
to some projects these terms apply, to some they don't, but the important thing is not the documents, it's the outcome for the stakeholders (to tie this to another thread of yours ), especially the customer. Sometimes the customer won't even produce a requirements document, sometimes the customer will even do the technical specification. Well, the customer's paying, so what's to stop him?



I agree with you, but it always depends what customer you have. If you are lucky the customer doesn't know all processes themself. But what if the customer know those standard processes (IEEE, DIN, etc.). What will you do then?

Originally posted by Stan James:
Everybody's WHAT is somebody else's HOW.
...
So what's an SRS to you may be somethign totally different to me. Bummer.
...
Then a requirement is replaced by a new one. Heh, wasn't really REQUIRED was it?
...
Long and mayabe useless answer, but this is such a fuzzy business. All the teams I know struggle with it, and the company's direction is to add more layers of people and docs and handoffs, which seems ... can't think of a nicer word right now ... wrong.



Well said, and it's a dilemma isn't it . We all face this fuzziness and want more transparency in our business. That's why I try to get a clearer picture of it, here in this thread.

Originally posted by Ilja Preuss:
... As a consquence, analysis needs to be an ongoing activity throughout the whole project - declaring it "done" before you start coding will ignore so much valuable feedback from actually implementing and using the system that it significantly reduces the project's chance of success.



I'm not against that at all . I only want to make a clear distinction between the WHAT document and the HOW document and their commonly used names.

Unfortunately, SRS can stand for both System Requirements Specification or Software Requirements Specification .

Another question in this respect . How valuable do you think are such standardization bodies like PMI, IEEE, DIN etc.?

Regards,
Darya
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A nice overview of IEEE's documents including all kinds of requirements specifications can be found at IEEE's Richard Thayer website.



On slide P04-17 of his CSDP Exam Preparatory Course you can find IEEE's Software Engineering Lifecycle Model.

CSDP stands for IEEE Computer Society's Certified Software Developer Professional exam.

Regards,
Darya
[ April 28, 2007: Message edited by: Darya Akbari ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Darya Akbari:
I only want to make a clear distinction between the WHAT document and the HOW document and their commonly used names.



But why would you want to do that?

There are a quantrillion of things that need to be communicated in a software development project. I don't think that categorizing them in "what" and "how" helps in actually communicating them. (Setting aside that I don't think *documents* are the perfect way to communicate them.)


Another question in this respect . How valuable do you think are such standardization bodies like PMI, IEEE, DIN etc.?



I think they are great for standardizing hardware interfaces, paper sizes etc. I wouldn't want to live without DIN A4
[ April 28, 2007: Message edited by: Ilja Preuss ]
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Darya Akbari:
So this can be one origin why we have those naming conflicts. Despite of that, I don't think SRS is what you mean . The central word here is Software. To me Software is the HOW and System is the WHAT.



Let me be clear here:
Software requirements specification - what the software is responsible for.
Functional specificaton - what the software does to fulfill its responsibilities.
Non-functional specifications - other aspects that may not derive directly from the software requirements but that must be fulfilled for the software to be useful (performance, reliability, accessibility, manuals, etc.). In many cases some non-functional requirements either exist because of constraints from existing computer hardware infrastructure or dictate what computer hardware infrastructure is needed.

System is the term that defies definition here - its a generic term and can mean different things in different contexts. In many cases system means software + computer hardware infrastructure - in this context the responsibilities of the software and the way software fulfills those responsibilities drives the needs of the computer hardware infrastructure. However the existing computer hardware infrastructure and/or a limited infrastructure budget can place constraints on the ways in which the software can fulfill its responsibilities. As a rule of thumb it is usually cheaper to buy better hardware than to let non-essential complexity slip (to alleviate hardware constraints) into the software.

In other contexts system simply refer to multiple software applications collaborating to achieve some higher goal. In this case system is short for software system.

In other cases system may still only refer to software but that software is distributed because somebody, after reviewing the requirements, chose that architecture.

But what if the customer know those standard processes (IEEE, DIN, etc.). What will you do then?


They pay for them. With military contracts there are usually a number MIL-STD compliant documents that are deliverables as part of the overall contract. If you are doing business with such a client, you will have to deliver, and they will have to pay for it - it's part of the whole product. However you can always point out:
  • That they are getting less software for their value because a lot of the money/effort is diverted to generating documents.
  • They will get the software later than without the overhead.
  • They will get software that conforms to the documents but not necessarily the software they need.

  •  
    Darya Akbari
    Ranch Hand
    Posts: 1855
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    As I said the distinction between System and Software is not from me. It's IEEE definition of the world.

    What do you think of IEEE's SWEBOK effort. Is it rubbish?
     
    Peer Reynders
    Bartender
    Posts: 2968
    6
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Darya Akbari:
    What do you think of IEEE's SWEBOK effort. Is it rubbish?



    Context.
    The definitions are useful in the context established by the IEEE SWEBOK.

    However unless all parties involved in any communication agree a priori to adhere to the definitions of the IEEE's SWEBOK the term "system" could mean any one of a number of things. IEEE has for a long time established useful standards - however not all of them are in common usage. There are many people working in the software industry that
  • Do not know the contents of IEEE SWEBOK.
  • Do not know of the existance of IEEE SWEBOK.
  • Do not know of the existance of IEEE.

  • Also the IEEE is still at its roots an engineering society - there are still regularly heated debates about whether the term software engineering is actually appropriate.

    Software Is (Not) Like That
     
    Darya Akbari
    Ranch Hand
    Posts: 1855
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    To my opinion standardization bodies like IEEE, DIN, PMI, etc. are not to underestimate.

    It's easy to step over such standards and do it your own way. But instead inventing your own names for things, I tend to use the efforts already done by such standardization bodies.

    When you come up with your definition of the world, this is fine but no one else than you knows about it and you have to explain yourself again and again. Doesn't that bother you?

    Originally posted by Peer Reynders:
    I think you are getting a bit bogged down by trying to differentiate terms that are sometimes used interchangeably (I've often found that English word/term use is much less precise than what you might be used to in German). If I had to choose a (document heavy) definition for the requirements I would go with the "IEEE 830-1998 Recommended Practice for Software Requirements Specifications (ANSI/IEEE)".



    Peer you yourself gave me the IEEE hint . So it was easy for you to lay back and relax, being sure that everything else important is written down there. I see it the same way .

    Why is IEEE 830-1998 Recommended Practice for Software Requirements Specifications (ANSI/IEEE) OK for you and IEEE's SWEBOK again NOT OK?

    If you say because no one know SWEBOK, I can say the same thing about IEEE 830 (you brought that one). And don't let me get into a discussion of the different Agile processes and their definitions of the world.

    SWEBOK at least does not confuse these terms and make a clear distinction.

    Regards,
    Darya
    [ April 29, 2007: Message edited by: Darya Akbari ]
     
    Darya Akbari
    Ranch Hand
    Posts: 1855
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Ilja Preuss:
    But why would you want to do that?

    There are a quantrillion of things that need to be communicated in a software development project. I don't think that categorizing them in "what" and "how" helps in actually communicating them. (Setting aside that I don't think *documents* are the perfect way to communicate them.)



    Why I want separate between a WHAT document and a HOW document ? Don't you normally start a project after you signed a contract?

    One maybe the most important input to the contract between you and your customer is your HOW document. At least a condensed form of your HOW document should be included. Otherwise what are you talking about in such contract?

    Regards,
    Darya
    [ April 29, 2007: Message edited by: Darya Akbari ]
     
    Ilja Preuss
    author
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Darya Akbari:
    Why I want separate between a WHAT document and a HOW document ? Don't you normally start a project after you signed a contract?



    Typically.


    One maybe the most important input to the contract between you and your customer is your HOW document. At least a condensed form of your HOW document should be included. Otherwise what are you talking about in such contract?



    That, of course, depends on the contract, and that one depends on your relationship with the customer. Google for "optional scope contract", for example.

    Is it really the *HOW* you want to put into a contract. I would have expected the *WHAT*, but perhaps I'm still not understanding.

    Anyway, I don't think that it's very effective to try to fix all the WHAT and/or HOW before you start the project. So, assuming for the moment that this kind of differentiation actually makes sense, I don't think it makes sense to talk about *one* document that describes the aspect.
     
    Peer Reynders
    Bartender
    Posts: 2968
    6
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Darya Akbari:
    To my opinion standardization bodies like IEEE, DIN, PMI, etc. are not to be underestimated.
    ...
    So it was easy for you to lay back and relax, being sure that everything else important is written down there. I see it the same way



    If you want to "lay back and relax", you are in the wrong business . That's the problem with these large standardization bodies - they are too slow to keep up with one of the fastest developing fields of commercial endeavor (faster than any traditional engineering profession). The first draft of IEEE 830 was laid down in 1989, updated in 1993, and updated again in 1998. These best practices are firmly rooted in the Barry Boehm's 1986 spiral model which is an iterative version of the waterfall model. While it is iterative it still very much uses the "finish the prescribed task and then toss it over the wall" approach which slows down or kills valuable feedback.

    Don't get me wrong there is lots of good stuff in the SWEBOK. At the same time a lot of it doesn't take into account developments that have taken place within the last decade. For me the "agile era" dawned when Kent Beck's book "Extreme Programming Explained" was published in 2000 (there were precursors before that). It appealed to me as a developer because it meant that I could spend more time developing, building confidence in my product through unit tests, get a more immediate reaction from the client and spend less time writing hundreds of pages of documents that nobody would read before they signed them anyway (TAGRI). However in the bigger scheme of things it seemed a better way of operating because the 'new' approach addressed issues that the process and document heavy approaches usually couldn't get a grip on:
  • Reduce waste (i.e. the majority amount of effort is directed towards creation of the software (or 'system' if you like) for the client, not project control and compliancy enforcement). In other words: maximizing business value per unit of effort (you are supposed to have your client's best interest in mind, correct?).
  • Delivering the least software (or systems) with the smallest set of features to provide useful business value as early as possible to verify the clients needs as early as possible and to productively guide any further effort.
  • Delivering software (or systems) that the client needs - NOT the system that the client thought they needed at the beginning of the project (if in fact they had a clue of what they needed).


  • Anyway the agile manifesto expresses it much more eloquently.
    You have already noted the efforts of the ISO, IEEE, CMMI, etc. divert an awful lot of effort towards compliancy activities (Highsmith: APM, p.32-34).

    Also standardization of the software engineering terms isn't necessarily going to help you communicate more effectively with your client. Your client isn't interested in those - they want their business problem solved, so that they can keep up with the competition and stay in business a little bit longer. They know their business and that is their language. And even if you stay in the same business domain with a standardized language each organization tends to develop its own 'dialect'. This is why it is so important that you develop the project's Ubiquitous Language with your client, use it in communications with your client, and use it within your software (or system).

    Why is IEEE 830-1998 Recommended Practice for Software Requirements Specifications (ANSI/IEEE) OK for you and IEEE's SWEBOK again NOT OK?


    Go back and check; my words were: If I had to choose a (document heavy) definition for the requirements - my preference is definitely elsewhere.
    There is a good reason that the agile community usually avoids terms like software (or system) requirements, functional specifications etc. - it avoids hauling in all the associated baggage that those terms acquired in the pre-agile era. It's usually the traditionalist that are trying to seem more agile that drag those terms back.
    [ April 29, 2007: Message edited by: Peer Reynders ]
     
    Darya Akbari
    Ranch Hand
    Posts: 1855
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi,

    Ilja, I still have to go and read that "optional scope contract" stuff. I think it bears some interesting information.

    Originally posted by Peer Reynders:
    That's the problem with these large standardization bodies - they are too slow to keep up with one of the fastest developing fields of commercial endeavor (faster than any traditional engineering profession)



    It's not only a problem of IEEE, it's also a problem for the industry. Do you really think that you can move whole indutries this fast?

    How old are your customer's CEOs? I am talking about mid-size and big-size companies. The ones I know are in their 60s who I would call traditionalists .

    I've seen suppliers kicked out with their projects because the business analysts unnerved the CEO with their Agility. So please keep in mind that also overestimating Agile can be dangerous too.

    In Germany we have clear and distinct names for the two types of requirements specifications I asked for Pflichtenheft and Lastenheft.

    Lets summarize what we have so far in the anglo-saxon world:

  • Lastenheft (WHAT) - Statement of Work (PMI), System Requirements Specification
  • Pflichtenheft (HOW) - Proposal (PMI), Software Requirements Specification (IEEE)


  • I am not against Agile. What I don't like however is, when Agile itself is not clear about something simple like naming different types of requirements specifications.

    Regards,
    Darya
    [ April 30, 2007: Message edited by: Darya Akbari ]
     
    author
    Posts: 608
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    The desire to write detailed requirements specifications early in the lifecycle is often motivated by the desire to have an estimate early in the lifecycle, often for a fixed-price project. In practice this proves to be a very poor way to work. In The Dire Consequences of Fixed-Price IT Projects I explore some of the challenges with this approach.

    You might find Agile Requirements Modeling and Agile Documentation to be of interest. The goal should be to understand and then implement effectively the requirements of your stakeholders. Documentation at best is a sideline.

    - Scott
    reply
      Bookmark Topic Watch Topic
    • New Topic