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.

Requirement Development – Iterative Model

What is Requirement Specification? What is Software Requirement? What is requirement Engineering?
Before we answer these questions on Requirement Management, and requirement Specifications, let’s talk about the following!
  1. A process is a description of how to accomplish a work activity
  2. A procedure is a set of steps for accomplishing the work tasks of a process
  3. A technique is the way an individual accomplishes a procedure

This is it that we have in Software development. How can you be a brilliant Software Developer! Ah, Amit, C’mon, you must have had lost your senses! We’re good developers / Testers, and Project managers!

Do you really think so, if you do, let me know how many items out of the mentioned below you follow while doing development!

  • Do you follow coding style guidelines
  • Do you follow code documentation guidelines
  • Do you really use debugging tools
  • Have you ever done your code being peer reviewed
  • Do you even know about testing strategies, procedures, and tools
  • Do you even know what periodic backups are
  • What isa version control system
  • Do you know how to use a defect tracking system
  • What isa design documentation tool
  • What is with requirements traceability tool
  • What do you know about project planning and tracking system

I bet most of you developing the code (and no offence here), would know at max about 2 or 3 of these. Reason, well primarily you don’t think that it is necessary OR it’s not your responsibility! Whatever is your reason, of you’re not following all the above you would surely be successful in your career BUT only in very short run!

Now here is a thing which we all should be aware of. Your project may follow the ‘Waterfall’ approach, BUT it is not necessary that during the requirement gathering phase too you have to follow the same model. You can always and in fact should always utilize various approaches for doing various activities of SDLC.

Here is how you should do Requirement Development using Iterative approach.

Requirement in an Iterative way!

Requirement in an Iterative way!

Now let’s talk about the Process flow for Requirement Development.

Why is it that my entire focus is on Requirement Analysis and not on other aspects of SDLC. Think about it! Majority of the time project failure is because of Improper Requirement Gathering—Yes, believe me, this is from experience!

Any available Software Projects workflow will have varied components, and requirement development is one of them.

Requirement Analysis Work Flow

Requirement Analysis Work Flow

Below mentioned is the COMPLETE detail on how Requirement should be done, following the requirement iteration flow!

Requirement Analysis - How

Requirement Analysis - How

Did I ever tell you what Requirement actually is?

 

Requirement is : The external (user) view of the system
                                                                              Which Includes
Functional requirements (what must the system do?)

                                                                              Which are

Prioritized as Essential, Desirable, Optional

and prioritized within categories, which also has

Quality attributes (how well must the system do it?)

                                                                              Which Includes
Safety, security, reliability, performance, throughput, capacities

Can also be prioritized
– e.g., security versus performance
• Usually apply to multiple (perhaps all) elements of the system
• Each operational requirement is tagged as “valid” or “design goal”

Simple isn’t it…Cheers! We will start with Project Planning Tomorrow!