Easily Transforming Requirements into a Solution

Premise

Through this paper: Easily Transforming Requirements into a Solution, we look to discuss the need for an innovative solution that enables rapid transformation of complex system requirements into robust systems, and which can also be further modified quickly to create additional new systems with ease.

Software development is a complex affair. One of the most crucial aspects of software development is systems requirements. Requirements are descriptions of the services that a software system must provide and the constraints under which it must operate[1}. System requirements analysis in any systems engineering and software engineering project is critical in ensuring successful execution and delivery of a software product.

What makes system requirements an intricate process is the fact that it circumscribes the needs or conditions that go into the development of a new or altered software product. So it also determines the scope for conflicting requirements of the various stakeholders involved in the process and encompasses the various tasks that go into formalizing a software development requirement document[2}. This typically includes analysis, verification, validation, and often, continuous monitoring and ongoing management.

The Fundamental challenge

There are various types of requirements that go into a systems requirement document e.g., user requirements, system requirements and software development requirements or specifications. Further, requirements can be functional, non-functional and domain specific.

To transform systems requirements into a workable software system, there is need for a language. Language can be natural language (structured or unstructured), diagrammatic and  tabular specifications, graphical notations or mathematical equations. Verbal unstructured natural language is typically used for documenting user requirements whereas complex system requirements are documented using structured natural language.

The difference between verbal language and a program language can really be qualified in terms of exceptions to the rules. A language’s suitability for automation is dependent on its rules, exceptions, and ease of defining and formalizing concrete objectives. Here, by language I mean any language – be it English language or C++ (a programming language); and by objectives I mean a concise, rule-bound description of the purpose with a statement.

All languages share some key fundamentals:

Objectivity – The point of any language is to communicate. This is defined as the objective. An objective for communication can be to:

1. Share information
2. Deliver instructions
3. Entice, enthrall or entertain

Statement – Statements are the building blocks of a language. They are designed to convey information. This may be in the following forms:

1. Formalism – The rigidity of the rules surrounding the conceptualization and delivery of a statement. In a rigid language, you may form one statement according to solid firm rules, with little variation.
2. Anomalism – In a free and more informal / creative language, you may have more freedom to construct the statement.

Transformation – The ultimate goal of language is to transform objectives and statements containing information required to create a system into a system that performs the desired operations.

In the example of a computer language, we have an objective to create a system that does operations X and Y. The process of transforming those objectives (i.e, requirements) into a functional digital system currently requires extensive authorship by various programmers, designers, testers, etc.

Now, the questions arise:

1. How do we execute that transformation without all of these people?
2. How do we simplify the process of delivering on an objective?
3. How do we transform system requirements into a system without all the hassle?
4. Does a future exist where requirements can be instantly translated into a system without the involvement of all of the different people?

To address the above questions, we will have to view software development from a radically new perspective. As transformation changes in the future, the actual code body becomes unimportant and the Rule Document becomes critical. That is where the major change is.

Critics might argue that if Rules become primary, whereas the actual language or code becomes secondary, innovation and creativity could get stifled. However, that is not at all true. There is a divide between creative and disposable content and functionality. Allocating critical resources to operations that are redundant and repetitive and result in output that is mundane is simply an opportunity cost. Disposable content and functionality should be readily available and should not cost time and resources. Once created, it should be simply and readily modifiable for more and more additional use cases. When this is achieved, critical resources can be freed from performing mundane tasks and instead be allocated toward the creation of more advanced Rules.

We need to get to the point of Boutique Software:  Couture Applications created on-demand to respond to our needs. How do we get there?

1. Stage 1: The Objective Transformation: a Build-based Methodology (Let’s Build) handled by experts who define the Rules.
2. Stage 2+:  Average people will slowly demand access to Objective Transformation, but will need tools that are easier to handle and produce more reliable outcomes.

The ultimate result will be higher efficiency and lower cost of development.

Citations

1. “Software Requirements”, http://www.inf.ed.ac.uk/teaching/courses/cs2/LectureNotes/CS2Ah/SoftEng/se02.pdf , Accessed: Friday April 17th, 2015
2. Wikipedia: “Requirements analysis” http://en.wikipedia.org/wiki/Requirements_analysis Accessed: Friday April 17th, 2015