Technical Specification – CMMi

After having discussed in detail about the Requirement Development and Management, we are going to start with Technical Solution. But before we start with that, we would need to understand few terms:

What is Specification?

• A software requirements specification (SRS) is a technical requirement document that describes in detail the externally visible characteristics of a software.
• A SRS is not the same as a statement of user needs OR ‘Requirement docs’. The SRS says what the product will be.
• The SRS can include Plain English text, structured text, diagrams, tables,rules, etc.
• Parts of the SRS include:
  • Environmental requirements: OS, platform, interoperability, standards, etc.
  • Non-functional requirements: security, usability, efficiency, etc.
  • Feature specifications: precisely describe each feature
  • Use cases: examples of how a user accomplishes a goal by using one or more features

What is Design?

• A design document explains the implementation that will satisfy the requirements of the SRS.
• There are many aspects of the system that you need to design:
  • Division of the system into components
  • APIs and dependencies between components
  • Classes, attributes. operations, and relationships within each component
  • Data representation in the database or even files
  • Key algorithms and conditions that affect the overall design
• Many notations are used in design
  • Plain English or structured English
  • Many types of UML diagrams
  • Pseudo-code, other diagrams as needed

What is the Difference Between SRS and Design?

• The SRS describes precisely what the system will do.
  • It is based on customer needs
  • It defines stages for design and system testing
• Customers should be able to review SRS and help validate it.
  • Validation of requirements means checking the written requirements against reality!
• Design outlines how the system will work.
  • It is based on the SRS
  • It sets the stage for implementation as well as integration testing
• Usually development team needs to review the design.

What Do They Have in Common?

• Both SRS and Technical Design documents are technical documents that need to be precise.
  • At times the same notation is used for multiple purposes
• Both need to be reviewed by stakeholders and defects must be corrected.

What Makes a Good Specification?

• The 4-C’s of requirements states:
  • Clear: It should be understandable so that all stakeholders can participate in validation and developers know what to build and test
  • Concise: Short requirements are more understandable and maintainable. And, they often are more precise
  • Correct: Incorrect requirements will lead to major rework and reduced revenue.
  • Complete: Incomplete requirements also leads to major rework and last-minute schedule changes.
• The specification should not bias the design or implementation.
  • Don’t get ahead of yourself, you will do design later, this is very important, and make sure you understand this!
  • Design details can make the SRS harder for non-technical stakeholders to understand
  • You may come up with better ideas for the design later but you should NEVER change the SRS unless your goals for the product change.

Related articles

• Requirement Development – Iterative Model (seeingfuture.wordpress.com)
• How do they do it – Requirement Management – CMMi (seeingfuture.wordpress.com)
• CMMi – Requirement Development Part – III (seeingfuture.wordpress.com)

 

Never ever say this about requirements….

I’m not the first person to come to this conclusion, but over the years, I’ve really come to dislike the entire concept of a “requirement.”

I’ve learned that so many things that look like “requirements” really are just a perception, or assumption, or an illusion.

Customers especially think they have “requirements” but really they’re just a hypothesis on what might solve some probably unstated problem.

Stakeholders have “requirements” that are really just their personal theories or assumptions on what might solve again a probably unstated problem.

On the other hand, I’ve learned that the true requirements are often not at all obvious at the start, and mostly emerge later when observing and interacting with real users.

I’ve also learned that the design directions you take will often lead to very different functional requirements.  It really is true that form and function are completely intertwined.  The old Waterfall theory of software had it essentially backwards.

It’s also rarely black and white, where a requirement is either totally absolutely essential, or not.  Very often you can build up the value in one area to compensate for other areas.  Or, if something isn’t feasible technically, we can come up with other approaches that suffice, or even work better.

I find defining and designing product is more like cooking in this respect in that if an ingredient is unavailable, you can often get creative and substitute something else or a combination of things that aren’t quite the same but may be even better.  It’s the result that matters, not our pre-conceptions.

I much prefer Agile methods like Scrum over Waterfall because of how much less weight is given to “requirements” in Scrum.  However, even if expressed in a user story, there are still dangers with Product Owners and their teams thinking something is more of a “requirement” than it really is.

Our only real requirement is to discover product solutions that work well for our users, our customers and our business.

Related articles

• Leading a Scrummy lifestyle: Part One (DanielOdio.com)