Each requirement you write represents a single market need, that you either satisfy or fail to satisfy. A well written requirement is independently deliverable and represents an incremental increase in the value of your software. That is the definition of an atomic requirement. Read on to see why atomic requirements are important.
Category Archives: Software requirements specification
SRS Plan of Attack
How do you approach starting a small requirements project as part of a large initiative within a massive enterprise? Do you boil the ocean? Your customer knows she needs “requirements” to give to her development team. She asks you – what will you deliver, and how long will it take? Great questions. If you have to write a statement of work, with time/cost estimates, and a list of deliverables – what would you do?
Posted in Business Analysis, Product Management, Requirements, Requirements Models, Requirements gathering, Software requirements specification
Tagged actor hierarchy, brd, enterprise requirements, enterprise software requirements, estimation, managing data, scoping, software requirements specification, SRS
5 Comments
Requirements Details – How Much is Enough?
What is the right level of detail for writing requirements? What about for writing specifications (functional, non-functional requirements, etc)? The answer is that there is no one answer. But there are guidelines, and reasons to write more detail, or less detail – for any given product or project, and any given team. The reason we write requirements is so that they can be read. Understanding the readers is the key to determining which details to include in the requirements.
Posted in Agile, Business Analysis, Product Management, Requirements, Requirements Models, Requirements gathering, Software development, Software requirements specification, Use Cases
Tagged business requirements, concise requirements, functional requirements, level of detail for requirements, managing data, non-functional requirements, requirements details, requirements level of detail
1 Comment
Ignoring The Requirements, Watching The Discussion
Almost a month ago, we published an article titled Broken Requirements Ecosystem. That article built on a discussion thread at Seilevel. Since that time, the original thread has grown, and a new one has been spawned at the Catalyze site.
In short, the question was asked on the Seilevel forum- why are specs sometimes ignored by developers, and four possible reasons were suggested. We followed up with our view, and the discussion picked up again, this time at Catalyze.
- Original discussion thread on Seilevel’s forum: Reasons Reqs Go Unread (Discussion from 19 Jun to 26 Jun )
- Article at Tyner Blain: Broken Requirements Ecosystem (Written on 21 Jun, Discussion to 26 Jun)
- Thread spawned on the Catalyze forum: Broken Requirements Ecosystem (Discussion from 23 Jun to 15 Jul)
Even if you read our article before, go back and follow the discussions again – starting with Seilevel’s article, and progressing to ours, following up with the conversation at Catalyze.
Broken Requirements Ecosystem
There’s an interesting thread on Seilevel’s requirements forum about why developers don’t read the specs and how to fix this problem. Sometimes the developers throw away the requirements. And that’s bad. But it is a symptom. Something is broken at a higher level.
Read the rest of the article …
APR: Mixing It Up With Design And Requirements
With a definition of the important use cases for our agile project, we can move to the logical next step – which is what exactly?
Prototyping.
Posted in Agile, Agile Project: Ratings, Product Management, Requirements, Requirements Models, Requirements gathering, Software development, Software requirements specification, UML Modeling, Use Cases
Tagged agile case study, agile project, agile requirements management, agile software development, Design, managing data, prototyping
4 Comments
Another Use For ‘Why?’
“Why?” The question is our inspiration and our muse. “Why?” is the justification for our requirements. The key to identifying “What?” and “When?”, which lead to “How?” and “How Much?” But there is another use for “Why?” – communication of intent (with stakeholders and implementers). Requirements documents are artifacts, but they are also dynamic documents. By documenting “Why?” a requirement is a requirement, we make it easier for future readers to understand.
Posted in Business Analysis, Communication, Requirements, Software requirements specification, Writing
Tagged asking why, documenting intent, documenting justifications, documenting requirements, justifying requirements, managing data, requirements documentation, requirements intent, requirements justification
5 Comments
Latest Articles
Comments on all Articles
