sugantharaja · January 12, 2016 08:01
diff --git a/Immortal Requirements b/Immortal Requirements
 A healthy tree starts with a small seed and a good product has its foundation in its requirements. Designers of product or service or software need to identify the requirements that are correct and complete. Need is the mother of all creations. Need is good for talking, but not fit for implementation as it is a vague statement. One cannot create a product out of need. So we have to convert the need into requirements, which is precise and means the same thing (or unambiguous) to whom so ever it is presented. To make things easy, I will use the term ‘product’ which includes the meaning of ‘product’, ‘software’ and ‘service’, as all of them goes through the same steps from cradle to grave.

 The typical milestones in a product development are stakeholder inputs, requirements specification, technical specification, development, testing and hand-over. We talk a lot about Product Development Life Cycle (PDLC) or Software Development Life Cycle (SDLC) on daily basis. But the problem is PDLC / SDLC undermines the importance of requirements. It restricts the use of requirements to the developmental phase alone. Most of the companies lose track of the requirements once a product is rolled out or handed over to the customer. Recently one of my student told me that she is working on a project where she is going through 1000’s of lines of code of a legacy system just to recreate the requirements that is the basis for this system. When we replace a legacy system with an advanced system, the scope of the new system is (R + DR), meaning almost all the original requirements and some more additional requirements. We need to understand that requirements are immortal, they never die. They live in one or the other product. Requirements are like soul and product is like body. So don’t limit requirements to Product Development Life Cycle (PDLC) but take it to Greater Life Cycle (GLC).



 We started the memory lane (product evolution) from punched card, magnetic tape, floppy disk, compact disk, hard drive, USB drive, Solid State Drive (SSD) and now cloud. Though the products changed from punched card to SSD, but the original requirement that was behind the punched card never changed. What is that requirement? A device to store information. In each stage of the product evolution and technology changes the original requirement is preserved, but we added DR in each stage with more functional and non-functional aspects.

 Why we need to think about the Greater Life Cycle? The requirements are immortal. They grow but doesn’t shrink over a period. By preserving and managing the requirements, organisations will cut down lots of unnecessary expenses that are directed towards retracing the requirements such as deriving requirements from the code of a legacy system, understanding the requirements behind the product supplied by a vendor, etc. Because no system is permanent. System need to be replaced as the requirement evolves and the technology changes. The total cost of managing a process will be reduced by preserving the requirements beyond the PDLC / SDLC. This is the business case for having requirements management tools within your organisation. It will not be too far in the future that companies will have a position called ‘Custodian of Requirements’ who will be entrusted with ownership, maintenance and upkeep of all the requirements of an organisation.

 What are the stages in Greater Life Cycle? The Greater Life Cycle is composed of enterprise analysis, PDLC and Product Life Cycle (PLC). All organisations on the face of earth have certain needs, problems and opportunities. There are both internal and external forces that are constantly acting on organisations that create these needs, problems and opportunities. Hence organisations cannot maintain the status quo (being static) but rather constantly change to adopt to meet the dictum of the internal and external forces. Internal forces are coming from within the organisation say a CEO wants to enter into a new market or to introduce new product in an existing market. External forces are coming from regulatory bodies, customers and competitors. The members of an organisation who realises this need, problem and opportunity will come out with a business proposal which will be submitted to the management.

 Business proposals are essentially the vehicles that communicate the need, problem or opportunity to the management. These business proposals are asking for certain capabilities to satisfy a need, solve a problem or to capitalise an opportunity. In an ideal situation, these proposals need to be processed by an enterprise analyst, who will transform the business proposal into a business case. Business requirements are the focus of enterprise analyst. That is what the business wants to accomplish. Using the business case, the enterprise analyst will justify to the management why or why not the organisation should invest on this business proposal. When the management approves the business case, a project is born or else the business case is rejected and also the corresponding business proposal.
 Once the business case is approved, a project is launched and this marks the start of Product Development Life Cycle (PDLC). The PDLC is composed of business analysis, system design, project implementation and testing. During business analysis, the business analyst elicits the information from stakeholders and comes out with the requirements specification. Then this requirements specification (job of a business analyst) is translated into technical specification (job of a systems analyst). This technical specification will be implemented by the project manager. At the end of PDLC the product is launched into the market or handed over to the client. At this point, the Product Life Cycle (PLC) commences.

 Product Life Cycle (PLC) has four stages such as introduction, growth, maturity and decline. During introduction the market learns about the product. Then the product becomes popular in the market in the growth stage. At maturity the product sales plateaus. During PLC the changes in requirements and new requirements will be adopted and new models or versions will be released. But the overall nature of the product is more or less same. It is not possible to completely change this product. A new technology may completely disrupt the existence of this product. This may happen from the same organisation or from a competitor organisation. Then finally this product is no longer wanted in the market and reaches its end-of-life. Here the requirements (soul) departs the product (body) and start living in another product until it finds yet another product. Hey requirements, you make our life easy by offering better and better products … you are truly immortal in this material world!
	A healthy tree starts with a small seed and a good product has its foundation in its requirements. Designers of product or service or software need to identify the requirements that are correct and complete. Need is the mother of all creations. Need is good for talking, but not fit for implementation as it is a vague statement. One cannot create a product out of need. So we have to convert the need into requirements, which is precise and means the same thing (or unambiguous) to whom so ever it is presented. To make things easy, I will use the term ‘product’ which includes the meaning of ‘product’, ‘software’ and ‘service’, as all of them goes through the same steps from cradle to grave.

	The typical milestones in a product development are stakeholder inputs, requirements specification, technical specification, development, testing and hand-over. We talk a lot about Product Development Life Cycle (PDLC) or Software Development Life Cycle (SDLC) on daily basis. But the problem is PDLC / SDLC undermines the importance of requirements. It restricts the use of requirements to the developmental phase alone. Most of the companies lose track of the requirements once a product is rolled out or handed over to the customer. Recently one of my student told me that she is working on a project where she is going through 1000’s of lines of code of a legacy system just to recreate the requirements that is the basis for this system. When we replace a legacy system with an advanced system, the scope of the new system is (R + DR), meaning almost all the original requirements and some more additional requirements. We need to understand that requirements are immortal, they never die. They live in one or the other product. Requirements are like soul and product is like body. So don’t limit requirements to Product Development Life Cycle (PDLC) but take it to Greater Life Cycle (GLC).



	We started the memory lane (product evolution) from punched card, magnetic tape, floppy disk, compact disk, hard drive, USB drive, Solid State Drive (SSD) and now cloud. Though the products changed from punched card to SSD, but the original requirement that was behind the punched card never changed. What is that requirement? A device to store information. In each stage of the product evolution and technology changes the original requirement is preserved, but we added DR in each stage with more functional and non-functional aspects.

	Why we need to think about the Greater Life Cycle? The requirements are immortal. They grow but doesn’t shrink over a period. By preserving and managing the requirements, organisations will cut down lots of unnecessary expenses that are directed towards retracing the requirements such as deriving requirements from the code of a legacy system, understanding the requirements behind the product supplied by a vendor, etc. Because no system is permanent. System need to be replaced as the requirement evolves and the technology changes. The total cost of managing a process will be reduced by preserving the requirements beyond the PDLC / SDLC. This is the business case for having requirements management tools within your organisation. It will not be too far in the future that companies will have a position called ‘Custodian of Requirements’ who will be entrusted with ownership, maintenance and upkeep of all the requirements of an organisation.

	What are the stages in Greater Life Cycle? The Greater Life Cycle is composed of enterprise analysis, PDLC and Product Life Cycle (PLC). All organisations on the face of earth have certain needs, problems and opportunities. There are both internal and external forces that are constantly acting on organisations that create these needs, problems and opportunities. Hence organisations cannot maintain the status quo (being static) but rather constantly change to adopt to meet the dictum of the internal and external forces. Internal forces are coming from within the organisation say a CEO wants to enter into a new market or to introduce new product in an existing market. External forces are coming from regulatory bodies, customers and competitors. The members of an organisation who realises this need, problem and opportunity will come out with a business proposal which will be submitted to the management.

	Business proposals are essentially the vehicles that communicate the need, problem or opportunity to the management. These business proposals are asking for certain capabilities to satisfy a need, solve a problem or to capitalise an opportunity. In an ideal situation, these proposals need to be processed by an enterprise analyst, who will transform the business proposal into a business case. Business requirements are the focus of enterprise analyst. That is what the business wants to accomplish. Using the business case, the enterprise analyst will justify to the management why or why not the organisation should invest on this business proposal. When the management approves the business case, a project is born or else the business case is rejected and also the corresponding business proposal.
	Once the business case is approved, a project is launched and this marks the start of Product Development Life Cycle (PDLC). The PDLC is composed of business analysis, system design, project implementation and testing. During business analysis, the business analyst elicits the information from stakeholders and comes out with the requirements specification. Then this requirements specification (job of a business analyst) is translated into technical specification (job of a systems analyst). This technical specification will be implemented by the project manager. At the end of PDLC the product is launched into the market or handed over to the client. At this point, the Product Life Cycle (PLC) commences.

	Product Life Cycle (PLC) has four stages such as introduction, growth, maturity and decline. During introduction the market learns about the product. Then the product becomes popular in the market in the growth stage. At maturity the product sales plateaus. During PLC the changes in requirements and new requirements will be adopted and new models or versions will be released. But the overall nature of the product is more or less same. It is not possible to completely change this product. A new technology may completely disrupt the existence of this product. This may happen from the same organisation or from a competitor organisation. Then finally this product is no longer wanted in the market and reaches its end-of-life. Here the requirements (soul) departs the product (body) and start living in another product until it finds yet another product. Hey requirements, you make our life easy by offering better and better products … you are truly immortal in this material world!