Software Engineering for the 99%

One of the main areas that had me tough to crack was the concept of Software Engineering. For quite some time in my career, I was not able to get a grasp of the concept of Software Engineering. Well, I did understand the parts of it (I have not done a formal course on SW engineering to date).

Unlike other engineering disciplines (i.e. Civil, Mechanical, etc.) Software Engineering is.

• Comparatively new
• Changes Rapidly
• Much vast than other disciplines

Moreover, the software projects that I had worked are not that big in terms of manpower and man-hours. Nonetheless, those projects are complex for an individual or small team. After working on software projects long enough this is what I understood of Software engineering.

The Entities

There are three entities involved in Software Product development. An entity could be an individual, a small team or a large division.

1. Entity-1, says why to develop a Software product and also says who is asking (either explicitly or implicitly) for the Software Product.
2. Entity-2, has to know how to develop the Software and actually develop the software product that was asked to do by Entity-1.
3. Entity-3, basically checks whether Entity-2 did the job (as asked by Entity-1) and releases the Software Product to the outside world to use it.

Now, we can map the entities and the work they perform.

Entity-1 — Marketing Manager/Department or Management

Entity-2 — Software Development Engineer/Department

Entity-3 — Test and Release Engineer/Department

How does each Entity do transactions to each other so that a great Software Product is delivered? They can talk about verbally (meetings, phone calls, etc.) and by creating documents. The latter is what I am more interested in.

The Documents

Ok, what kind of documents to create? We can categorize the documents into three types

1. Requirements Documents or Specification
2. Design Documentation or Specification
3. Testing Documentation or Specifications

I also call them as RDT (Requirement, Design, and Test) documents. As it is logical, we always start with Requirements.

Requirements Documentation

The different types of requirements within the Software Product Development Cycle are

1. Marketing Requirement Specification
2. Functional Requirement Specification
3. Software Requirement Specification
4. Software Test Specification

Marketing Requirement Specification (MRS)

This is the root of all Specifications. This is a kind of Bible to that particular Software Product Development. Nobody questions this specification (Well, not at least after the specification is signed off), since this specification basically tells why the Software Product Needs to be built (Market Needs it) and also specifics on what the market needs from the Software Product.

Functional Requirement Specification (FRS)

This document is derived from the MRS. After the MRS is finalized, the software design team takes this requirement and asks, OK, what are the functions that the Software product needs to perform in order to satisfy the Market Requirement (as defined by MRS). Typically, this specification can be a joint effort by Marketing and Software Development or just by the Software Development Team.

Software Requirement Specification (SRS)

After finalizing the FRS, we know the functionalities required to satisfy the market needs, Now, Software Requirement Specification (SRS) defines what are the software modules or components that are needed in order achieve the functionalities defined in FRS. This document is the sole effort of the Software Development Engineer/Team. Care should be taken when developing this document as to just list the requirements and not delve into implementation, that’s the job of the design document.

Software Test Requirement Specification (STRS)

The Software Test Requirement Specification (STRS) is derived from the FRS. Once we know the functional requirement, we need to determine how these functionalities (after implemented) need to be tested. The Software Test Requirement Specification just lists out the functionalities that are to be tested. This document does not detail how these functionalities will be tested, that is the role of Software Test Procedure Specification.

Once the requirements are nailed down, then the next stage is the design and development.

Design and Development Specification

In the design and development stage, the Software Development team plays a key role in all the documents. There can be a number of design documents that can be developed based on the complexity of the project like, Software Architecture Document, Application Programming Interface (API) Design Document, Software Interface Document, etc. Instead, I prefer a single document called Detailed Design Document, which has sections for Architecture, API, and interfaces.

Detailed Design Document

The Detailed design document is derived from the FRS. Detailed Software Design document basically explains the overall architecture of the software and how each functionality listed in the FRS will be implemented or in other words what software functions or modules will be used in order to implement each functionality (input parameters, output results, etc.). Once the Detailed design is finalized. Now the actual development starts.

In parallel, the testing team/engineer starts working on the testing specification for the Software Product.

Software Test Procedure

Since the Software Test Requirement Specification (STRS) has already determined the functionalities that need to be tested. The next step would be to have a user manual for the tester as to how to perform those tests listed in the STRS. Typically, it’s called Software Test Procedure (STP). The STP takes each and every functionality listed in the STRS and expands in a step by step procedure as to how to test the functionality.

There it is… My understanding of Software Engineering, Of Course, this is nothing compared to tons of books and research done on this topic and I am no expert on this. Please feel free to correct me or give more of your thoughts in the comments section. This may be layman’s understanding of software engineering and that’s the point :).