Programming refers to the method of creating a sequence of instructions to enable the computer to perform a task. It is done by developing logic and then writing instructions in a programming language. A program can be written using various programming practices available. A programming practice refers to the way of writing a program and is used along with coding style guidelines. Some of the commonly used programming practices include top-down programming, bottom-up programming, structured programming, and information hiding.

Top-down Programming

Top-down programming focuses on the use of modules. It is therefore also known as modular programming. The program is broken up into small modules so that it is easy to trace a particular segment of code in the software program. The modules at the top level are those that perform general tasks and proceed to other modules to perform a particular task. Each module is based on the functionality of its functions and procedures. In this approach, programming begins from the top level of hierarchy and progresses towards the lower levels. The implementation of modules starts with the main module. After the implementation of the main module, the subordinate modules are implemented and the process follows in this way. In top-down programming, there is a risk of implementing data structures as the modules are dependent on each other and they nave to share one or more functions and procedures. In this way, the functions and procedures are globally visible. In addition to modules, the top-down programming uses sequences and the nested levels of commands.

Bottom-up Programming

Bottom-up programming refers to the style of programming where an application is constructed with the description of modules. The description begins at the bottom of the hierarchy of modules and progresses through higher levels until it reaches the top. Bottom-up programming is just the opposite of top-down programming. Here, the program modules are more general and reusable than top-down programming.

It is easier to construct functions in bottom-up manner. This is because bottom-up programming requires a way of passing complicated arguments between functions. It takes the form of constructing abstract data types in languages such as C++ or Java, which can be used to implement an entire class of applications and not only the one that is to be written. It therefore becomes easier to add new features in a bottom-up approach than in a top-down programming approach.

Structured Programming

Structured programming is concerned with the structures used in a computer program. Generally, structures of computer program comprise decisions, sequences, and loops. The decision structures are used for conditional execution of statements (for example, ‘if statement). The sequence structures are used for the sequentially executed statements. The loop structures are used for performing some repetitive tasks in the program.

Structured programming forces a logical structure in the program to be written in an efficient and understandable manner. The purpose of structured programming is to make the software code easy to modify when required. Some languages such as Ada, Pascal, and dBase are designed with features that implement the logical program structure in the software code. Primarily, the structured programming focuses on reducing the following statements from the program.

1. ‘GOTO’ statements.
2. ‘Break’ or ‘Continue’ outside the loops.
3. Multiple exit points to a function, procedure, or subroutine. For example, multiple ‘Return’ statements should not be used.
4. Multiple entry points to a function, procedure, or a subroutine.

Structured programming generally makes use of top-down design because program structure is divided into separate subsections. A defined function or set of similar functions is kept separately. Due to this separation of functions, they are easily loaded in the memory. In addition, these functions can be reused in one or more programs. Each module is tested individually. After testing, they are integrated with other modules to achieve an overall program structure. Note that a key characteristic of a structured statement is the presence of single entry and single exit point. This characteristic implies that during execution, a structured statement starts from one defined point and terminates at another defined point.

 Information Hiding

Information hiding focuses on hiding the non-essential details of functions and code in a program so that they are inaccessible to other components of the software. A software developer applies information hiding in software design and coding to hide unnecessary details from the rest of the program. The objective of information hiding is to minimize complexities among different modules of the software. Note that complexities arise when one program or module in software is dependent on several other programs and modules.

Information hiding is implemented with the help of interfaces. An interface is a medium of interaction for software components that are using the properties of the software modules containing data. The implementation of interfaces depends on the syntax and process. Examples of interface include constants, data types, types of procedures, and so on. Interfaces protect other parts of programs when a software design is changed.

Generally, the interfaces act as a foundation to modular programming (top-down programming) and object-oriented programming. In object-oriented programming, interface of an object comprises a set of methods, which are used to interact with the objects of the software programs. Using information hiding, a single program is divided into several modules. These modules are independent of each other and can be used interchangeably in other software programs.

To understand the concept of information hiding, let us consider an example of a program written for ‘car’. The program can be organized in several ways. One is to arrange modules without using information hiding. In this case, the modules can be created as ‘front part’, ‘middle part’, and ‘rear part’. On the other hand, creating modules using information hiding includes specifying names of modules such as ‘engine’ and ‘steering’.

On comparison, it is found that modules created without using information hiding affect other modules. This is because when a module is modified, it affects the data, which does not require modification. However, if modules are created using information hiding, then modules are concerned only with specific segments of the program and not the whole program or other parts of the program. In our example, this statement means that the module ‘engine’ does not have any affect on the module ‘steering’.

This methodology refers to a set of well-documented procedures and guidelines used in the analysis, design, and implementation of programs. Coding methodology includes a diagrammatic notation for documenting the results of the procedure. It also includes an objective set (ideally quantified) of criteria for determining whether the results of the procedure are of the desired quality. The steps to use coding’ methodology are listed below.

1. The software development team begins its work by reviewing and understanding the design and requirements specification documents. These documents are essential for understanding user requirements and creating a framework for the software code.
2. In case the software development team is unable to understand user requirements correctly and further clarification is required, the queries are sent back to the user. In addition, the software development team also returns the requirements that are understood by them.
3. After the requirements are clearly understood by the software development team, the design and specifications are implemented in source code, supporting files, and the header files. Note that while writing the software code, the coding style guidelines should be followed. In some cases, there may be a proposal of change in hardware or software specifications. However, the requests for change are implemented only after the approval of the user.
4. When the software code is completely written, it is compiled along with other required files.
5. Code inspection and reviews are conducted after the compilation. These methods are used to correct and verify errors in the software code.
6. Software testing is carried out to detect and correct errors in each module of the software code.
7. After the software code is tested, the software is delivered to the user along with the relevant code files, header files, and documentation files.

In Software Coding Process further change and clarifications are required in the design or SRS, the software development team raises a query, which is sent to the user with the document containing what the software development team understood from the documents sent by the user. Changes are made only when the user has a positive response to the queries raised by the software development team.

Writing an efficient software code requires a thorough knowledge of programming. This knowledge can be implemented by following a coding style which comprises several guidelines that help in writing the software code efficiently and with minimum errors. These guidelines, known as coding guidelines, are used to implement individual programming language constructs, comments, formatting, and so on. These guidelines, if followed, help in preventing errors, controlling the complexity of the program, and increasing the readability and understandability of the program.

A set of comprehensive coding guidelines encompasses all aspects of code development. To ensure that all developers work in a harmonized manner (the source code should reflect a harmonized style as a single developer had written the entire code in one session), the developers should be aware of the coding guidelines before starting a software project. Moreover, coding guidelines should state how to deal with the existing code when the software incorporates it or when maintenance is performed.

Since there are numerous programming languages for writing software codes, each having different features and capabilities, coding style guidelines differ from one language to another. However, there are some basic guidelines which are followed in all programming languages. These include naming conventions, commenting conventions, and formatting conventions.

There are certain rules for naming variables, functions and methods in the software code. These naming conventions help software; developers in understanding the use of a particular variable or function. The guidelines used to assign a name to any variable, function, and method are listed below.

• All the variables, functions, and methods should be assigned names that make the code more understandable to the reader. By using meaningful names, the code can be self-explanatory, thus, minimizing the effort of writing comments for variables. For example, if two variables are required to refer to ‘sales tax’ and ‘income tax’, they should be assigned names such as ‘sales Tax’ and ‘income Tax’.
• For names, a full description in a commonly spoken language (for example, English) should be used. In addition, the use of abbreviations should be avoided. For example, variable names like ‘contact Number’ and ‘address’ should be used instead of ‘cno’ and ‘add’.
• Short and clear names should be assigned in place of long names. For ‘example, ‘multiply The Two Numbers’ can be shortened to ‘multiply Numbers’ as it is clear and short enough to be expressed in reasonable length.

In every programming language, there is a different naming convention for variables and constants in the software code. The commonly used conventions for naming variables and constants are listed in Table.

                 Table  Naming Conventions for Variables and Constants

As with variables and constants, there are some guidelines that should be followed while naming functions in the software code. These conventions are listed below.

• The names of functions should be meaningful and should describe the purpose of the function with clarity and briefness. Like variables, the names should be self-explanatory so that no additional description about the task of that function is required.
• The function name should begin with a verb. For example, the verb ‘display’ can be used for the function that displays the output on the screen. In case the verb itself is not descriptive, an additional noun or adjective can be used with the verb. For example, the function name ‘add Marks’ should be used to clarify the function and its purpose.
• In case the function returns a Boolean value, the helping verbs ‘is’ and ‘has’ should be used as prefixes for the function name. For example, the function name ‘is Deposited’ or ‘has Deposited’ should be used for functions that return true or false values.

Comments are helpful in proper understanding of the code segment used in program. Commenting conventions should be used efficiently to make the code easy to grasp. Generally, two types of commenting conventions are used: file header comments and trailing comments.

File header comments are useful in providing information related to a file as a whole and comprise identification information such as date of creation, Dame of the creator, and a brief description of the software code.

Trailing comments are used to provide explanation of a single line of code. These comments are used to clarify the complex code. These also specify the function of the abbreviated variable names that are not clear. In some languages, trailing comments are used with the help of a double slash (//). The commenting conventions that are commonly followed in the software code are listed below.

• Comments should not be used to include information that is clearly understandable from the software.
• Comments should be used with important segments of code and code segments that are difficult to understand.
• Comments should be separated from the code to enhance readability of the software code.

Formatting (way of arranging a program in order to enhance readability) consists of indentation, alignment, and use of white spaces in the program. Consistency plays an important role while formatting a program in an organized way. A program with consistent formatting makes the code easier to read and understand. The commonly used formatting conventions are listed below.

• Indentation: This refers to one or more spaces left at the beginning of statements in the program. Indentation is useful in making the code easily readable. However, the spaces used for indentation should be followed in the entire program. The guidelines that are commonly followed while indenting a program are listed below.White spaces: These improve readability by minimizing the compactness of the code. Some of the guidelines for proper usage of spaces within the code are listed below.
  • Indentation should be used to highlight a nested block. Some nested blocks can be made with the help of ‘if-else’ and ‘do-while’ loops.
  • Indentation is required if the statement is large enough to fit in a single line.
  • Indentation should be consistent at the beginning and at the end of the braces in the program.

• There should be a space after placing a comma between two function arguments.
• There should be no space between a function name and parenthesis.
• There should be spaces to align the operators vertically to emphasize program structure and semantics.

 Implementing Coding Guidelines

If coding guidelines are used in a proper manner, errors can be detected at the time of writing the software code. Such detection in early stages helps in increasing the performance of the software as well as reducing the additional and unplanned costs of correcting and removing errors. Moreover, if a well-defined coding guideline is applied, the program yields a software system that is easy to comprehend and maintain. Some of the coding guidelines that are followed in a programming language are listed below.

• All the codes should be properly commented before being submitted to the review team.
• All curly braces should start from a new line.
• All class names should start with the abbreviation of each group. For example, AA and CM can be used instead of academic administration and course management, respectively.
• Errors should be mentioned in the following format: [error code]: [explanation]. For example, 0102: null pointer exception, where 0102 indicates the error code and null pointer exception is the name of the error.
• Every ‘if statement should be followed by a curly braces even if there exists only a single statement.
• Every file should contain information about the author of the file, modification date, and version information.

Similarly, some of the commonly used coding guidelines in a database (organized collection of information that is systematically organized for easy access and analysis) are listed below.

• Table names should start with TBL. For example, TBL_STUDENT.
• If table names contain one word, field names should start with the first three characters of the name of the table. For example, STU_FIRSTNAME.
• Every table should have a primary key.
• Long data type (or database equivalent) should be used for the primary key.

Advantages of Coding Guidelines

Coding guidelines supplement the language standard by defining acceptable and unacceptable usage of the programming language used. Acceptable usage avoids troublesome situations while unacceptable usage is conducive to errors or leads to misunderstanding of the written code. Properly implemented coding guidelines help the developer to limit program complexity, establish the basis for code review, and guard against compiler and common programming errors. Other advantages associated with coding guidelines are listed below and depicted.

• Increased efficiency: Coding guidelines can be used effectively to save time spent on gathering unnecessary details. These guidelines increase the efficiency of the software team while the software development phase is carried out. An efficient software code is fast and economical. Software coding guidelines are used to increase efficiency by making the team productive, thus, ensuring that the software is delivered to the user on time.
• Reduced costs: Coding guidelines are beneficial in reducing the cost incurred on the software project. This is possible since coding guidelines help in detecting errors in the early stages of the software development. Note that if errors are discovered after the software is delivered to the user, the process of rectifying them becomes expensive as additional costs are incurred on late detection, rework, and retesting of the entire software code.
• Reduced complexity: The written software code can be either simple or complex. Generally, it is observed that a complex segment of software code is more susceptible to errors than a segment containing a simple software code. This is because a complex software code reduces readability as well as understandability. In addition, the complex software code may be inefficient in functioning and use of resources. However, if the code is written using the given coding guidelines, the problem of complexity can be significantly avoided as the probability of error occurrence reduces substantially.
• Reduced hidden costs: Coding guidelines, if adhered to in a proper manner, help to achieve a high-quality software code. The software quality determines the efficiency of the software. Software quality is the degree to which user requirements are accomplished in the software along with conformity to standards. Note that if quality is not considered while developing the software, the cost for activities such as fixing errors, redesigning the software, and providing technical support increases considerably.
• Code reuse: Using coding guidelines, software developers are able to write a code that is more robust and create individual modules of the software code. The reason for making separate code segment is to enable reusability of the modules used in the software. A reusable module can be used a number of times in different modules in one or more software.
• Automated error prevention: The coding guidelines enable Automated Error Prevention (AEP).This assures that each time error occurs in software, the software development activity is improved to prevent similar errors in future. AEP begins with detecting errors in the software, isolating its cause, and then searching the cause of error generation. Coding guidelines are useful in preventing errors as they allow implementation of requirements that prevent the most common and damaging errors in the software code.

In addition to the above mentioned advantages, coding guidelines define appropriate metric thresholds. These thresholds help in reducing complexity, thus, minimizing the occurrence of errors. Software developers face increasing demands to demonstrate that development practices meet the accepted coding guidelines. This is essential for companies developing safety-critical software as well as those seeking CMM and ISO certification.

The code written for software should be according to the requirements of the users. A program is said to be good if the software code is flawless or contains minimum errors. For the effective performance of the software, some particular features are required in almost all languages that are used to write the software code. These features are listed below.

Simplicity: Software code should be written in a simple and concise manner. Simplicity should be maintained in the organization, implementation, and design of the software code.

Modularity: Breaking the software into several modules not only makes it easy to understand but also easy to debug. With the modularity feature, the same code segment can be reused in one or more software programs.

Design: Software code is properly designed if it is presented in a proper manner. The design of the software should be decided before beginning to write the software code. Writing the software code in a specific, consistent style helps other software developers in reviewing it.

Efficiency: A program is said to be efficient if it makes optimal use of the available resources.

Clarity: Software codes should be clear so that developers are able to understand the program without any complexity. Clarity can be achieved by using features such as simplicity, readability and modularity. Note that clarity comprises clarity of code, clarity of design, and clarity of purpose so that one knows what occurs at each level in the software program.

Accessibility: Software codes should be written in a way that the software components (for example, files and functions) are easily available and accessible. For the files and functions to be accessible, they should have meaningful names as well as supporting captions and text for each image. Similarly, there should be hyperlinks and navigation aids to assist the users in searching information from different sections of the software code.

Stability: Software codes are said to be stable if they are able to work correctly on different platforms without affecting their layout and consistency. To check for stability, software codes should be tested for errors and inconsistency.

IEEE defines software design documentation as ‘a description of software created to facilitate analysis, planning, implementation, and decision-making. This design description is -used as a medium for communicating software design information and can be considered as a blueprint or model of the system.

While developing SDD, the design should be described up to the refinement level that is sufficient for explaining every task including inter-task communications, data structures, and databases. No refinement of any task should be left to be made during the coding phase.

The information that the software design document should describe depends on various factors including the type of software being developed and the approach used in its development. A number of standards have been suggested to develop a software design document. However, the most widely used standard is by IEEE, which acts as a general framework. This general framework can be customized and adapted to meet the needs of a particular organization. This template consists of several sections, which are listed below.

1. Scope: Identifies the release or version of the system being designed. The system is divided into modules; the relationship between them and functionalities will be defined. Every iteration of the SDD document describes and identifies the software modules to be added or changed in a release.
2. References: Lists references (both hardware and software documents and manuals) used in the creation of the SDD that may be of use to the designer, programmer, user, or management personnel. This document is also considered useful for the readers of the document. In this section, any references made to the other documents including references to related project documents, especially the SRS are also listed. The existing software documentation (if any) is also listed.
3. Definition: Provides a glossary of technical terms used in the document along with their definitions.
4. Purpose: States the purpose of this document and its intended audience. This is meant primarily for individuals who will be implementing the system.
5. Design description information content: Consists of the following subsections.

.

1. Introduction: Since SDD represents the software design that is to be implemented, it should describe the design entities into which the system has been partitioned along with their significant properties and relationships.
2. Design entity: It is a software design component that is different from other design entities in terms of structure and function. The objective of creating design entities is to partition the system into a set of components that can be implemented and modified independently. Note that each design entity is assigned with a unique name and serves a specific purpose and function but all possess some common characteristics.
3. Design entity attributes: They are properties of the design entity and provide some factual information regarding the entity. Every attribute has an attached description, which includes references and design considerations. The attributes and their associated information are listed in Table.

                                            Table Attributes and Description

6. Design description organization: Consists of the following subsection.

7. Design views: They describe the software design in a comprehensive manner so that the process of information access and integration is simplified. The design of software can be viewed in multiple ways and each design view describes a distinct aspect of the system. Table lists various design views and their attributes.

                               Table Design Views and their Description

Software design reviews are a systematic, comprehensive, and well-documented inspection of design that aims to check whether the specified design requirements are adequate and the design meets all the specified requirements. In addition, they also help in identifying the problems (if any) in the design process. IEEE defines software design review as ‘a formal meeting at which a system’s preliminary or detailed design is presented to the user, customer, or other interested parties for comment and approval.’ These reviews are held at the end of the design phase to resolve issues (if any) related to software design decisions, that is, architectural design and detailed design (component-level and interface design) of the entire software or a part of it (such as a database).

The elements that should be examined while reviewing the software design include requirements and design specifications, verification and validation results produced from each phase of SOLe, testing and development plans, and all other project related documents and activities. Note that design reviews are considered as the best mechanism to ensure product quality and to reduce the potential risk of avoiding the problems of not meeting the schedules and requirements.

Types of Software Design Reviews

Generally, the review process is carried out in three steps, which corresponds to the steps involved in the software design process. First, a preliminary design review is conducted with the customers and users to ensure that the conceptual design (which gives an idea to the user of what the system will look like) satisfies their requirements. Next, a critical design review is conducted with analysts and other developers to check the technical design (which is used by the developers to specify how the system will work) in order to critically evaluate technical merits of the design. Next, a program design review is conducted with the programmers in order to get feedback before the design is implemented.

Preliminary Design Review

During preliminary design review, the high-level architectural design is reviewed to determine whether the design meets all the stated requirements as well as the non-functional requirements. This review is conducted to serve the following purposes.

1. To ensure that the software requirements are reflected in the software architecture
2. To specify whether effective modularity is achieved
3. To define interfaces for modules and external system elements
4. To ensure that the data structure is consistent with the information domain
5. To ensure that maintainability has been considered
6. To assess the quality factors.

In this review, it is verified that the proposed design includes the required hardware and interfaces with the other parts of the computer-based system. To conduct a preliminary design review, a review team is formed where each member acts as an independent person authorized to make necessary comments and decisions. This review team comprises the following individuals.

1. Customers: Responsible for defining the software’s requirements.
2. Moderator: Presides over the review. The moderator encourages discussions, maintains the main objective throughout the review, settles disputes and gives unbiased observations. In short, he is responsible for the smooth functioning of the review.
3. Secretary: A silent observer who does not take part in the review process but records the main points of the review.
4. System designers: Includes people involved in designing not only the software but also the entire computer-based system.
5. Other stakeholders (developers) not involved in the project: Provide an outsider’s idea on the proposed design. This is beneficial as they can infuse ‘fresh ideas’, address issues of correctness, consistency, and good design practice.

If errors are noted in the review process then the faults are assessed on the basis of their severity. That is, if there is a minor fault it is resolved by the review team. However, if there is a major fault, the review team may agree to revise the proposed conceptual design. Note that preliminary design review is again conducted to assess the effectiveness of the revised (new) design.

Critical Design Review

Once the preliminary design review is successfully completed and the customer(s) is satisfied with the proposed design, a critical design review is conducted. This review is conducted to serve the following purposes.

1. To assure that there are no defects in the technical and conceptual designs
2. To verify that the design being reviewed satisfies the design requirements established in the architectural design specifications
3. To assess the functionality and maturity of the design critically
4. To justify the design to the outsiders so that the technical design is more clear, effective and easy to understand

In this review, diagrams and data (sometimes both) are used to evaluate alternative design strategies and how and why the major design decisions have been taken. Just like for the preliminary design review, a review team is formed to carry out a critical design review. In addition to the team members involved in the preliminary design review, this team comprises the following individuals.

1. System tester: Understands the technical issues of design and compare them with the design created for similar projects.
2. Analyst: Responsible for writing system documentation.
3. Program designer for this project: Understands the design in order to derive detailed program designs.

Similar to a preliminary design review, if discrepancies are noted in the critical design review process the faults are assessed on the basis of their severity. A minor fault is resolved by the review team. If there is a major fault, the review team may agree to revise the proposed technical design. Note that a critical design review is conducted again to assess the effectiveness of the revised (new) design.

Program Design Review

Once the critical design review is successfully completed, a program design review is conducted to obtain feedback before the implementation (coding) of the design. This review is conducted to serve the following purposes.

1. To assure the feasibility of the detailed design
2. To assure that the interface is consistent with the architectural design
3. To specify whether the design is compatible to implementation language
4. To ensure that structured programming constructs are used throughout
5. To ensure that the implementation team is able to understand the proposed design.

A review team comprising system designers, a system tester, moderator, secretary and analyst is formed to conduct the program design review. The review team also includes program designers and developers. The program designers, after completing the program designs, present their plans to a team of other designers, analysts and programmers for comments and suggestions. Note that a successful program design review presents considerations relating to coding plans before coding begins.

Software Design Review Process

Design reviews are considered important as in these reviews the product is logically viewed as the collection of various entities/components and use-cases. These reviews are conducted at all software design levels and cover all parts of the software units. Generally, the review process comprises three criteria, as listed below.

• Entry criteria: Software design is ready for review.
• Activities: This criterion involves the following steps.
  1. Select the members for the software design review team, assign them their roles, and prepare schedules for the review.
  2. Distribute the software design review package to all the reviewing participants.
  3. Participants check the completeness and conformance of the design to the requirements in addition to the efficiency of the design. They also check the software for defectsal1,d if defects are found, they discuss those defects with one another. The recorder documents the defects along with the suggested action items and recommendations.
  4. The design team rectifies the defects (if any) in design and makes the required changes in the appropriate design review material.
  5. The software development manager obtains the approval of the software design from the software project manager.

• Exit criteria: The software design is approved.

Evaluating Software Design Reviews

The software design review process is beneficial for everyone as the faults can be detected at an early stage, thereby reducing the cost of detecting errors and reducing the likelihood of missing a critical issue. Every review team member examines the integrity of the design and not the persons involved in it (that is, designers), which in turn emphasizes that the common ‘objective of developing a highly rated design is achieved. To check the effectiveness of the design, the review team members should address the following questions.

1. Is the solution achieved with the developed design?
2. Is the design reusable?
3. Is the design well structured and easy to understand?
4. Is the design compatible with other platforms?
5. Is it easy to modify or enlarge the design?
6. Is the design well documented?
7. Does the design use suitable techniques in order to handle faults and prevent failures?
8. Does the design reuse components from other projects, wherever necessary?

In addition to these questions, if the proposed system is developed using a phased development (like waterfall and incremental model), then the phases should be interfaced sufficiently so that an easy transition can take place from one phase to the other.

As soon as the first iteration of architectural design is complete, component-level design takes place. The objective of this design is to transform the design model into functional software. To achieve this objective, the component-level design represents -the internal data structures and processing details of all the software components (defined during architectural design) at an abstraction level, closer to the actual code. In addition, it specifies an interface that may be used to access the functionality of all the software components. [Read more…] about Component-Level Design in software engineering

Requirements of the software should be transformed into an architecture that describes the software’s top-level structure and identifies its components. This is accomplished through architectural design (also called system design), which acts as a preliminary ‘blueprint’ from which software can be developed. IEEE defines architectural design as ‘the process of defining a collection of hardware and software components and their interfaces to establish the framework for the development of a computer system.’ This framework is established by examining the software requirements document and designing a model for providing implementation details. These details are used to specify the components of the system along with their inputs, outputs, functions, and the interaction between them. An architectural design performs the following functions.

1. It defines an abstraction level at which the designers can specify the functional and performance behaviour of the system.

2. It acts as a guideline for enhancing the system (when ever required) by describing those features of the system that can be modified easily without affecting the system integrity.

3.  It evaluates all top-level designs.

4.  It develops and documents top-level design for the external and internal interfaces.

5.  It develops preliminary versions of user documentation.

6. It defines and documents preliminary test requirements and the schedule for software integration.

7.  The sources of architectural design are listed below.

8.  Information regarding the application domain for the software to be developed

9.  Using data-flow diagrams

10. Availability of architectural patterns and architectural styles.

Architectural design is of crucial importance in software engineering during which the essential requirements like reliability, cost, and performance are dealt with. This task is cumbersome as the software engineering paradigm is shifting from monolithic, stand-alone, built-from-scratch systems to componentized, evolvable, standards-based, and product line-oriented systems. Also, a key challenge for designers is to know precisely how to proceed from requirements to architectural design. To avoid these problems, designers adopt strategies such as reusability, componentization, platform-based, standards-based, and so on.

Though the architectural design is the responsibility of developers, some other people like user representatives, systems engineers, hardware engineers, and operations personnel are also involved. All these stakeholders must also be consulted while reviewing the architectural design in order to minimize the risks and errors.

Architectural Design Representation

Architectural design can be represented using the following models.

1. Structural model: Illustrates architecture as an ordered collection of program components
2. Dynamic model: Specifies the behavioral aspect of the software architecture and indicates how the structure or system configuration changes as the function changes due to change in the external environment
3. Process model: Focuses on the design of the business or technical process, which must be implemented in the system
4. Functional model: Represents the functional hierarchy of a system
5. Framework model: Attempts to identify repeatable architectural design patterns encountered in similar types of application. This leads to an increase in the level of abstraction.

Architectural Design Output

The architectural design process results in an Architectural Design Document (ADD). This document consists of a number of graphical representations thatcomprises software models along with associated descriptive text. The softwaremodels include static model, interface model, relationship model, and dynamic processmodel. They show how the system is organized into a process at run-time.

Architectural design document gives the developers a solution to the problem stated in the Software Requirements Specification (SRS). Note that it considers only those requirements in detail that affect the program structure. In addition to ADD, other outputs of the architectural design are listed below.

1. Various reports including audit report, progress report, and configuration status accounts report
2. Various plans for detailed design phase, which include the following
3. Software verification and validation plan
4. Software configuration management plan
5. Software quality assurance plan
6. Software project management plan.

Architectural Styles

Architectural styles define a group of interlinked systems that share structural and semantic properties. In short, the objective of using architectural styles is to establish a structure for all the components present in a system. If an existing architecture is to be re-engineered, then imposition of an architectural style results in fundamental changes in the structure of the system. This change also includes re-assignment of the functionality performed by the components.

By applying certain constraints on the design space, we can make different style-specific analysis from an architectural style. In addition, if conventional structures are used for an architectural style, the other stakeholders can easily understand the organization of the system.

A computer-based system (software is part of this system) exhibits one of the many available architectural styles. Every architectural style describes a system category that includes the following.

1. Computational components such as clients, server, filter, and database to execute the desired system function
2. A set of connectors such as procedure call, events broadcast, database protocols, and pipes to provide communication among the computational components
3. Constraints to define integration of components to form a system
4. A semantic model, which enable the software designer to identify the characteristics of the system as a whole by studying the characteristics of its components.

Some of the commonly used architectural styles are data-flow architecture, object oriented architecture, layered system architecture, data-centered architecture, and call and return architecture. Note that the use of an appropriate architectural style promotes design reuse, leads to code reuse, and supports interoperability.

Data-flow Architecture

Data-flow architecture is mainly used in the systems that accept some inputs and transform it into the desired outputs by applying a series of transformations. Each component, known as filter, transforms the data and sends this transformed data to other filters for further processing using the connector, known as pipe. Each filter works as an independent entity, that is, it is not concerned with the filter which is producing or consuming the data. A pipe is a unidirectional channel which transports the data received on one end to the other end. It does not change the data in anyway; it merely supplies the data to the filter on the receiver end.

Most of the times, the data-flow architecture degenerates a batch sequential system. In this system, a batch of data is accepted as input and then a series of sequential filters are applied to transform this data. One common example of this architecture is UNIX shell programs. In these programs, UNIX processes act as filters and the file system through which UNIX processes interact, act as pipes. Other well-known examples of this architecture are compilers, signal processing systems, parallel programming, functional programming, and distributed systems. Some advantages associated with the data-flow architecture are listed below.

1. It supports reusability.
2. It is maintainable and modifiable.
3. It supports concurrent execution.
4. Some disadvantages associated with the data-flow architecture are listed below.
5. It often degenerates to batch sequential system.
6. It does not provide enough support for applications requires user interaction.
7. It is difficult to synchronize two different but related streams.

Object-oriented Architecture

In object-oriented architectural style, components of a system encapsulate data and operations, which are applied to manipulate the data. In this style, components are represented as objects and they interact with each other through methods (connectors). This architectural style has two important characteristics, which are listed below.

1. Objects maintain the integrity of the system.
2. An object is not aware of the representation of other objects.
3. Some of the advantages associated with the object-oriented architecture are listed below.
4. It allows designers to decompose a problem into a collection of independent objects.
5. The implementation detail of objects is hidden from each other and hence, they can be changed without affecting other objects.

Layered Architecture

In layered architecture, several layers (components) are defined with each layer performing a well-defined set of operations. These layers are arranged in a hierarchical manner, each one built upon the one below it. Each layer provides a set of services to the layer above it and acts as a client to the layer below it. The interaction between layers is provided through protocols (connectors) that define a set of rules to be followed during interaction. One common example of this architectural style is OSI-ISO (Open Systems Interconnection-International Organization for Standardization) communication system.

Data-centered Architecture

A data-centered architecture has two distinct components: a central data structure or data store (central repository) and a collection of client software. The datastore (for example, a database or a file) represents the current state of the data andthe client software performs several operations like add, delete, update, etc., onthe data stored in the data store. In some cases, the data storeallows the client software to access the data independent of any changes or theactions of other client software.

In this architectural style, new components corresponding to clients can be added and existing components can be modified easily without taking into account other clients. This is because client components operate independently of one another.

A variation of this architectural style is blackboard system in which the data store is transformed into a blackboard that notifies the client software when the data (of their interest) changes. In addition, the information can be transferred among the clients through the blackboard component.

Some advantages of the data-centered architecture are listed below.

1. Clients operate independently of one another.
2. Data repository is independent of the clients.
3. It adds scalability (that is, new clients can be added easily).
4. It supports modifiability.
5. It achieves data integration in component-based development using blackboard.

Call and Return Architecture

A call and return architecture enables software designers to achieve a program structure, which can be easily modified. This style consists of the following two substyles.

1. Main program/subprogram architecture: In this, function is decomposed into a control hierarchy where the main program invokes a number of program components, which in turn may invoke other components.

1. Remote procedure call architecture: In this, components of the main or subprogram architecture are distributed over a network across multiple computers.

Data design is the first design activity, which results in less complex, modular and efficient program structure. The information domain model developed during analysis phase is transformed into data structures needed for implementing the software. The data objects, attributes, and relationships depicted in entity relationship diagrams and the information stored in data dictionary provide a base for data design activity. During the data design process, data types are specified along with the integrity rules required for the data. For specifying and designing efficient data structures, some principles should be followed. These principles are listed below.

1. The data structures needed for implementing the software as well-as the operations that can be applied on them should be identified.
2. A data dictionary should be developed to depict how different data objects interact with each other and what constraints are to be imposed on the elements of data structure.
3. Stepwise refinement should be used in data design process and detailed design decisions should be made later in the process.
4. Only those modules that need to access data stored in a data structure directly should be aware of the representation of the data structure.
5. A library containing the set of useful data structures along with the operations that can be performed on them should be maintained.
6. Language used for developing the system should support abstract data types.

The structure of data can be viewed at three levels, namely, program component level, application level, and business level. At the program component level, the design of data structures and the algorithms required to manipulate them is necessary, if high-quality software is desired. At the application level, it is crucial to convert the data model into a database so that the specific business objectives of a system could be achieved. At the business level, the collection of information stored in different databases should be reorganized into data warehouse, which enables data mining that has an influential impact on the business.

Once the requirements document for the software to be developed is available, the software design phase begins. While the requirement specification activity deals entirely with the problem domain, design is the first phase of transforming the problem into a solution. In the design phase, the customer and business requirements and technical considerations all come together to formulate a product or a system. [Read more…] about Principles of Software Design & Concepts in Software Engineering

Several tools are used in the organizations to define and document requirements. These tools differ from each other in their features, capabilities, and goals. These distinct characteristics provide a foundation to select and customize tools for different software projects. Some of the commonly used requirements tools are listed in Table.

                                    Table Requirements Engineering Tools

Once a system has been deployed, new requirements inevitably emerge. It is difficult for the users to anticipate the effect of these new requirements (if a new system is developed for these requirements) on the organization. Thus, to understand and control changes to system requirements, requirements management is performed.

Requirements management can be defined as a process of eliciting, documenting, organizing, and controlling changes to the requirements. Generally, the process of requirements management begins as soon as the requirements document is available, but ‘planning’ for managing the changing requirements should start during the requirements elicitation process.

The essential activities performed in requirements management are listed below.

1. Recognizing the need for change in the requirements
2. Establishing a relationship amongst stakeholders and involving them in the requirements engineering process
3. Identifying and tracking requirements attributes.

Requirements management enables the development team to identify, control, and track requirements and changes that occur as the software development process progresses. Other advantages associated with the requirements management are listed below.

1. Better control of complex projects: This provides the development team with a clear understanding of what, when, and why the software is to be delivered. The resources are allocated according to user-driven priorities and relative implementation effort.
2. Improved software quality: This ensures that the software performs according to the requirements to enhance software quality. This can be achieved when the developers and testers have a precise understanding of what to develop and test.
3. Reduced project costs and delays: This minimizes errors early in the development cycle as it is expensive to ‘fix’ errors at the later stages of the development cycle. As a result, the project costs also reduce.
4. Improved team communication: This facilitates early involvement of users to ensure that their needs are achieved.
5. Easing compliance with standards and regulations: This ensures that standards involved with software compliance and process improvement have a thorough understanding of requirements management. For example, CMM addresses requirements management as one of the first steps to improve software quality.
6. All the user requirements are specified in the software requirements specification. The project manager as part of requirements management tracks the requirements for the current project and those which are planned for the next release.

Requirements Management Process

Requirements management starts with planning, which establishes the level of requirements management needed. After planning, each requirement is assigned a unique ‘identifier’ so that it can be crosschecked by other requirements. Once requirements are identified, requirements tracing is performed.

Requirements tracing is a medium to trace requirements from the start of development process till the software is delivered to the user. The objective of requirements tracing is to ensure that all the requirements are well understood and included in test plans and test cases. Various advantages of requirements tracing are listed below.

1. It verifies whether user requirements are implemented and adequately tested.
2. It enables user understanding of impact of changing requirements.

Trace ability techniques facilitate the impact of analysis on changes of the project, which is under development. Traceability information is stored in a traceability matrix, which relates requirements to stakeholders or design module. The traceability matrix refers to a table that correlates high-level requirements with the detailed requirements of the product. Mainly, five types of traceability tables are maintained. These are listed in Table.

In a traceability matrix, each requirement is entered in a row and column of the matrix. The dependencies between different requirements are represented in the cell at a row and column intersection. ‘U’ in the row and column intersection indicates the dependencies of the requirements in the row on the column and ‘R’ in the row and column intersection indicates the existence of some other weaker relationship between the requirements.

                                      Table Types of Traceability Tables

Note that a traceability matrix is useful when less number of requirements are to be managed. However, traceability matrices are expensive to maintain when a large system with large requirements is to be developed. This is because large requirements are not easy to manage. Due to this, the traceability information of large system is stored in the ‘requirements database’ where each requirement is explicitly linked to related requirements. This helps to assess how a change in one requirement affects the different aspects of the system to be developed.

Requirements Change Management

Requirements change management is used when there is a request or proposal for a change in the requirements. The advantage of this process is that the changes to the proposals are managed consistently and in a controlled manner. Note that many activities of requirements management are similar to software configuration management activities.

An efficient requirements change management process undergoes a number of stages for changes to the requirements. These stages are listed below.

1. Problem analysis and change specification: The entire process begins with identification of problems to the requirements. The problem or proposal is analyzed to verify whether the change is valid. The outcome of the analysis is provided to the ‘change requester’ and a more specific requirements change proposal is then made.
2. Change analysis and costing: The effect of a change requested on the requirement is assessed according to traceability information. The cost for this can be estimated on the basis of modification made to the design and implementation. After the analysis is over, a decision is made whether changes are to be made.
3. Change implementation: Finally, the changes are made to the requirements document, system design and implementation. The requirements document is organized in such a manner so that changes to it can be made without extensive rewriting. Minimizing the external references and making document sections modular achieves changeability in the document. By doing this, individual sections can be changed and replaced without affecting other parts of the document.

The development of software begins once the requirements document is ‘ready’. One of the objectives of this document is to check whether the delivered software system is acceptable. For this, it is necessary to ensure that the requirements specification contains no errors and that it specifies the user’s requirements correctly. Also, errors present in the SRS will adversely affect the cost if they are detected later in the development process or when the software is delivered to the user. Hence, it is desirable to detect errors in the requirements before the design and development of the software begins. To check all the issues related to requirements, requirements validation is performed.

In the validation phase, the work products produced as a consequence of requirements engineering are examined for consistency, omissions, and ambiguity. The basic objective is to ensure that the SRS reflects the actual requirements accurately and clearly. Other objectives of the requirements document are listed below.

1. To certify that the SRS contains an acceptable description of the system to be implemented
2. To ensure that the actual requirements of the system are reflected in the SRS
3. To check the requirements document for completeness, accuracy, consistency, requirement conflict‘, conformance to standards and technical errors.

Requirements validation is similar to requirements analysis as both processes review the gathered requirements. Requirements validation studies the ‘final draft’ of the requirements document while requirements analysis studies the ‘raw requirements’ from the system stakeholders (users). Requirements validation and requirements analysis can be summarized as follows:

1. Requirements validation: Have we got the requirements right?
2. Requirements analysis: Have we got the right requirements?

Various inputs such as requirements document, organizational knowledge, and organizational standards are shown. The requirements document should be formulated and organized according to the standards of the organization. The organizational knowledge is used to estimate the realism of the requirements of the system. The organizational standards are specified standards followed by the organization according to which the system is to be developed.      

The output of requirements validation is a list of problems and agreed actions of the problems. The lists of problems indicate the problems encountered in the” requirements document of the requirements validation process. The agreed actions is a list that displays the actions to be performed to resolve the problems depicted in the problem list.

Requirements Review

Requirements validation determines whether the requirements are substantial to design the system. The problems encountered during requirements validation are listed below.

1. Unclear stated requirements
2. Conflicting requirements are not detected during requirements analysis
3. Errors in the requirements elicitation and analysis
4. Lack of conformance to quality standards.

To avoid the problems stated above, a requirements review is conducted, which consists of a review team that performs a systematic analysis of the requirements. The review team consists of software engineers, users, and other stakeholders who examine the specification to ensure that the problems associated with consistency, omissions, and errors are detected and corrected. In addition, the review team checks whether the work products produced during the requirements phase conform to the standards specified for the process, project, and the product.

At the review meeting, each participant goes over the requirements before the meeting starts and marks the items which are dubious or need clarification. Checklists are often used for identifying such items. Checklists ensure that no source of errors, whether major or minor, is overlooked by the reviewers. A ‘good’ checklist consists of the following.

1. Is the initial state of the system defined?
2. Is there a conflict between one requirement and the other?
3. Are all requirements specified at the appropriate level of abstraction?
4. Is the requirement necessary or does it represent an add-on feature that may not be essentially implemented?
5. Is the requirement bounded and has a clear defined meaning?
6. Is each requirement feasible in the technical environment where the product or system is to be used?
7. Is testing possible once the requirement is implemented?
8. Are requirements associated with performance, behavior, and operational characteristics clearly stated?
9. Are requirements patterns used to simplify the requirements model?
10. Are the requirements consistent with the overall objective specified for the system/product?
11. Have all hardware resources been defined?
12. Is the provision for possible future modifications specified?
13. Are functions included as desired by the user (and stakeholder)?
14. Can the requirements be implemented in the available budget and technology?
15. Are the resources of requirements or any system model (created) stated clearly?

The checklists ensure that the requirements reflect users’ needs and provide groundwork for design. Using the checklists, the participants specify the list of potential errors they have uncovered. Lastly, the requirements analyst either agrees to the presence of errors or states that no errors exist.

Other Requirements Validation Techniques

A number of other requirements validation techniques are used either individually or in conjunction with other techniques to check the entire system or parts of the system. The selection of the validation technique depends on the appropriateness and the size of the system to be developed. Some of these techniques are listed below.

1. Test case generation: The requirements specified in the SRS document should be testable. The test in the validation process can reveal problems in the requirement. In some cases test becomes difficult to design, which implies that the requirement is difficult to implement and requires improvement.
2. Automated consistency analysis: If the requirements are expressed in the form of structured or formal notations, then CASE tools can be used to check the consistency of the system. A requirements database is created using a CASE tool that checks the entire requirements in the database using rules of method or notation. The report of all inconsistencies is identified and managed.
3. Prototyping: Prototyping is normally used for validating and eliciting new requirements of the system. This helps to interpret assumptions and provide an appropriate feedback about the requirements to the user. For example, if users have approved a prototype, which consists of graphical user interface, then the user interface can be considered validated.

The output of the requirements phase of the software development process is Software Requirements Specification (SRS) (also known as requirements document). This document lays a foundation for software engineering activities and is created when entire requirements are elicited and analyzed. SRS is a formal document, which acts as a representation of software that enables the users to review whether it (SRS) is according to their requirements. In addition, it includes user requirements for a system as well as detailed specifications of the system requirements.

IEEE defines software requirements specification as, ‘a document that clearly and precisely describes each of the essential requirements (functions, performance, design constraints and quality attributes) of the software and the external interfaces. Each requirement is defined in such a way that its achievement can be objectively verified by a prescribed method, for example, inspection, demonstration, analysis or test.’ Note that requirements specification can be in the form of a written document, a mathematical model, a collection of graphical models, a prototype, and so on.

Essentially, what passes from requirements analysis activity to the specification activity is the knowledge acquired about the system. The need for maintaining a requirements document is that the modeling activity essentially focuses on the problem structure and not its structural behavior. While in SRS, performance constraints, design constraints, and standard compliance recovery are clearly specified. This information helps in developing a proper design of the system. Various other purposes served by SRS are listed below.

1. Feedback: Provides a feedback, which ensures to the user that the organization (which develops the software) understands the issues or problems to be solved and the software behavior necessary to address those problems.
2. Decompose problem into components: Organizes the information and divides the problem into its component parts in an orderly manner.
3. Validation: Uses validation strategies applied to the requirements to acknowledge that requirements are stated properly.
4. Input to design: Contains sufficient detail in the functional system requirements to devise a design solution.
5. Basis for agreement between the user and the organization: Provides a complete description of the functions to be performed by the system. In addition, it helps the users to determine whether the specified requirements are accomplished.
6. Reduce the development effort: Enables developers to consider user requirements before the designing of the system commences. As a result, ‘rework’ and inconsistencies in the later stages can be reduced.
7. Estimating costs and schedules: Determines the requirements of the system and thus enables the developer to have a ‘rough’ estimate of the total cost and schedule of the project.

SRS is used by various individuals in the organization. System customers need SRS to specify and verify whether requirements meet the desired needs. In addition, SRS enables the managers to plan for the system development processes. System engineers need a requirements document to understand what system is to be developed. These engineers also require this document to develop validation tests for the required system. Lastly, requirements document is needed by system maintenance engineers to use the requirement and the relationship between its parts.

The requirements document has diverse users. Therefore, along with communicating the requirements to the users it also has to define the requirements in precise detail for developers and testers. In addition it should also include information about possible changes in the system, which can help system designers avoid restricted decisions on design. SRS also helps maintenance engineers to adapt the system to new requirements.

Characteristics of SRS

Software requirements specification should be accurate, complete, efficient, and of high quality, so that it does not affect the entire project plan. An SRS is said to be of high quality when the developer and user easily understand the prepared document. Other characteristics of SRS are discussed below.

1. Correct: SRS is correct when all user requirements are stated in the requirements document. The stated requirements should be according to the desired system. This implies that each requirement is examined to ensure that it (SRS) represents user requirements. Note that there is no specified tool or procedure to assure the correctness of SRS. Correctness ensures that all specified requirements are performed correctly.
2. Unambiguous: SRS is unambiguous when every stated requirement has only one interpretation. This implies that each requirement is uniquely interpreted. In case there is a term used with multiple meanings, the requirements document should specify the meanings in the SRS so that it is clear and easy to understand.
3. Complete: SRS is complete when the requirements clearly define what the software is required to do. This includes all the requirements related to performance, design and functionality.
4. Ranked for importance/stability: All requirements are not equally important, hence each requirement is identified to make differences among other requirements. For this, it is essential to clearly identify each requirement. Stability implies the probability of changes in the requirement in future.
5. Modifiable: The requirements of the user can change, hence requirements document should be created in such a manner that those changes can be modified easily, consistently maintaining the structure and style of the SRS.
6. Traceable: SRS is traceable when the source of each requirement is clear and facilitates the reference of each requirement in future. For this, forward tracing and backward tracing are used. Forward tracing implies that each requirement should be traceable to design and code elements. Backward tracing implies defining each requirement explicitly referencing its source.
7. Verifiable: SRS is verifiable when the specified requirements can be verified with a cost-effective process to check whether the final software meets those requirements. The requirements are verified with the help of reviews. Note that unambiguity is essential for verifiability.
8. Consistent: SRS is consistent when the subsets of individual requirements defined do not conflict with each other. For example, there can be a case when different requirements can use different terms to refer to the same object. There can be logical or temporal conflicts between the specified requirements and some requirements whose logical or temporal characteristics are not satisfied. For instance, a requirement states that an event ‘a’ is to occur before another event ‘b’. But then another set of requirements states (directly or indirectly by transitivity) that event ‘b’ should occur before event ‘a’.

Structure of SRS

The requirements document is devised in a manner that is easier to write, review, and maintain. It is organized into independent sections and each section is organized into modules or units. Note that the level of detail to be included in the SRS depends on the type of the system to be developed and the process model chosen for its development. For example, if a system is to be developed by an external contractor, then critical system specifications need to be precise and detailed. Similarly, when flexibility is required in the requirements and where an in-house development takes place, requirements documents can be less detailed.

Since the requirements document serves as a foundation for subsequent software development phases, it is important to develop the document in the prescribed manner. For this, certain guidelines are followed while preparing SRS. These guidelines are listed below.

1. Functionality: It should be separate from implementation.
2. Analysis model: It should be developed according to the desired behavior of a system. This should include data and functional response of a system to various inputs given to it.
3. Cognitive model: It should be developed independently of design or implementation model. This model expresses a system as perceived by the users.
4. The content and structure of the specification: It should be flexible enough to accommodate changes.
5. Specification: It should be robust. That is, it should be tolerant towards incompleteness and complexity.

The information to be included in SRS depends on a number of factors, for example, the type of software being developed and the approach used in its development. If software is developed using the iterative development process, the requirements document will be less detailed as compared to that of the software developed for critical systems. This is because specifications need to be very detailed and accurate in these systems. A number of standards have been suggested to develop a requirements document. However, the most widely used standard is by IEEE, which acts as a general framework. This general framework can be customized and adapted to meet the needs of a particular organization.

Each SRS fits a certain pattern; thus, it is essential to standardize the structure of the requirements document to make it easier to understand. For this IEEE standard is used for SRS to organize requirements for different projects, which provides different ways of structuring SRS. Note that in all requirements documents, the first two sections are the same.

This document comprises the following sections.

1. Introduction: This provides an overview of the entire information described in SRS. This involves purpose and the scope of SRS, which states the functions to be performed by the system. In addition, it describes definitions, abbreviations, and the acronyms used. The references used in SRS provide a list of documents that is referenced in the document.
2. Overall description: It determines the factors which affect the requirements of the system. It provides a brief description of the requirements to be defined in the next section called ‘specific requirement’. It comprises the following sub-sections.
3. Product perspective: It determines whether the product is an independent product or an integral part of the larger product. It determines the interface with hardware, software, system, and communication. It also defines memory constraints and operations utilized by the user.
4. Product functions: It provides a summary of the functions to be performed by the software. The functions are organized in a list so that they are easily understandable by the user:
5. User characteristics: It determines general characteristics of the users.
6. Constraints: It provides the genera1 description of the constraints such as regulatory policies, audit functions, reliability requirements, and so on.
7. Assumption and dependency: It provides a list of assumptions and factors that affect the requirements as stated in this document.
8. Apportioning of requirements: It determines the requirements that can be delayed until release of future versions of the system.
9. Specific requirements: These determine all requirements in detail so that the designers can design the system in accordance with them. The requirements include description of every input and output of the system and functions performed in response to the input provided. It comprises the following subsections.
10. External interface: It determines the interface of the software with other systems, which can include interface with operating system and so on. External interface also specifies the interaction of the software with users, hardware, or other software. The characteristics of each user interface of the software product are specified in SRS. For the hardware interface, SRS specifies the logical characteristics of each interface among the software and hardware components. If the software is to be executed on the existing hardware, then characteristics such as memory restrictions are also specified.
11. Functions: It determines the functional capabilities of the system. For each functional requirement, the accepting and processing of inputs in order to generate outputs are specified. This includes validity checks on inputs, exact sequence of operations, relationship of inputs to output, and so on.
12. Performance requirements: It determines the performance constraints of the software system. Performance requirement is of two types: static requirements and dynamic requirements. Static requirements (also known as capacity requirements) do not impose constraints on the execution characteristics of the system. These include requirements like number of terminals and users to be supported. Dynamic requirements determine the constraints on the execution of the behavior of the system, which includes response time (the time between the start and ending of an operation under specified conditions) and throughput (total amount of work done in a given time).
13. Logical database of requirements: It determines logical requirements to be stored in the database. This includes type of information used, frequency of usage, data entities and relationships among them, and so on.
14. Design constraint: It determines all design constraints that are imposed by standards, hardware limitations, and so on. Standard compliance determines requirements for the system, which are in compliance with the specified standards. These standards can include accounting procedures and report format. Hardware limitations implies when the software can operate on existing hardware or some pre-determined hardware. This can impose restrictions while developing the software design. Hardware limitations include hardware configuration of the machine and operating system to be used.
15. Software system attributes: It provide attributes such as reliability, availability, maintainability and portability. It is essential to describe all these attributes to verify that they are achieved in the final system.
16. Organizing Specific Requirements: It determines the requirements so that they can be properly organized for optimal understanding. The requirements can be organized on the basis of mode of operation, user classes, objects, feature, response, and functional hierarchy.
17. Change management process: It determines the change management process in order to identify, evaluate, and update SRS to reflect changes in the project scope and requirements.
18. Document approvals: These provide information about the approvers of the SRS document with the details such as approver’s name, signature, date, and so on.
19. Supporting information: It provides information such as table of contents, index, and so on. This is necessary especially when SRS is prepared for large and complex projects.

It has been observed that the software engineer ‘reuses’ certain functions, classes, and/ or behavior across all the projects, which mayor may not form a part of the specific application domain. For example, features and functions described by a user interface are almost common, regardless of the application domain chosen. Analysis patterns refer to classes, functions, and other features that can be reused when developing applications within a specific application domain. The objectives of analysis patterns are listed below.

1. To quicken the requirements analysis phase by providing reusable analysis models with the description of both advantages and limitations.
2. To suggest several design patterns and feasible solutions to common problems in order to help the software designer translate an analysis model into a design model.

Analysis patterns have a unique pattern name, which allows the development team to refer to them with their pattern names. These patterns are stored in a repository so that the software engineer can refer to these patterns and reuse them while developing new software.

Information is stored in the analysis pattern, which can be viewed in the form of a template. The analysis pattern template, which is comprises the following sections.

1. Pattern name: Consists of important information (in the form of descriptor) about the analysis pattern. This descriptor is used within the analysis model when reference is made to a pattern.
2. Intent: Describes the problem that is addressed in an analysis pattern, which facilitates the software engineer to use analysis patterns in the specified application domain.
3. Motivation: Represents how an analysis pattern can be used to address a particular problem in the application domain with the help of a scenario.
4. External issues and contexts: Lists the external issues that affect the manner in which an analysis pattern works. The external issues include business related subjects, external technical constraints, and so on. In addition, external issues and contexts specify the external issues that are to be resolved by an analysis pattern.
5. Solution: Describes the procedure by which an analysis pattern is implemented in the analysis model.
6. Consequences: Describes the implementation effects of an analysis pattern into the application domain. It also provides a description of limitations that arises during its implementation.
7. Design: Describes the procedure of achieving analysis patterns by using the known design patterns.
8. Known uses: Provides information about the uses of an analysis pattern within the system.
9. Related patterns: Lists the analysis patterns that are related to the ‘chosen’ pattern.

IEEE defines requirements analysis as (1) the process of studying user needs to arrive at a definition of a system, hardware or software requirements. (2) The process of studying and refining system, hardware or software requirements.’ Requirements analysis helps to understand, interpret, classify, and organize the software requirements in order to assess the feasibility, completeness, and consistency of the requirements. Various other tasks performed using requirements analysis are listed below. [Read more…] about Requirements Analysis in Software Engineering

Requirements elicitation (also known as requirements capture and requirements acquisition) is a process of collecting information about software requirementsfrom different individuals such as users and other stakeholders. Stakeholders areindividuals who are affected by the system, directly or indirectly. They includeproject mangers, marketing personnel, consultants, software engineers,maintenance engineers, and the user.

Various issues may arise during requirements elicitation and may cause difficulties in understanding the software requirements. Some of the problems are listed below.

1. Problems of scope: This problem arises when the boundary of software (that is, scope) is not defined properly. Due to this, it becomes difficult to identify objectives as well as functions and features to be included in the software.
2. Problems of understanding: This problem arises when users are not certain about their requirements and thus are unable to express what they require in the software and which requirements are feasible. This problem also arises when users have no or little knowledge of the problem domain and are unable to understand the limitations of the computing environment of the software.
3. Problems of volatility: This problem arises when requirements change over time.
4. Requirements elicitation uses elicitation techniques, which facilitate software engineers to understand user requirements and software requirements needed to develop the proposed software.

Elicitation Techniques

Various elicitation techniques are used to identify the problem, determine its solution, and identify different approaches for the solution. These techniques also help the stakeholders to clearly express their requirements by stating all the important information. The commonly followed elicitation techniques are listed below.

1. Interviews: These are conventional ways of eliciting requirements, which help software engineers, users, and the software development team to understand the problem and suggest solutions for it. For this, the software engineer interviews the users with a series of questions. When an interview is conducted, rules are established for users and other stakeholders. In addition, an agenda is prepared before conducting interviews, which includes the important points (related to software) to be discussed among users and other stakeholders. An effective interview should have the following characteristics.
2. Individuals involved in interviews should be able to accept new ideas. Also, they should focus on listening to the views of stakeholders related to requirements and avoid biased views.
3. Interviews should be conducted in a defined context to requirements rather than in general terms. For this, users should start with a question or a requirements proposal.
4. Scenarios: These are descriptions of a sequence of events, which help to determine possible future outcomes before software is developed or implemented. Scenarios are used to test whether the software will accomplish user requirements. It also helps to provide a framework for questions to software engineers about users’ tasks. These questions are asked from users about future conditions (what-if) and procedures (how) in which they think tasks can be completed. Generally, a scenario includes the following information.
5. Description of what users expect when the scenario starts
6. Description of how to handle the situation when the software is not functioning properly
7. Description of the state of the software when the scenario ends.
8. Questionnaire: Questionnaire is an effective tool of gathering requirements and produces a written document. The major advantage of questionnaire is that it requires less effort and gathers information from many users in a very short time. In this method, preparing right and effective questionnaires is the critical issue. This is because different users work with different parts of the system, and have knowledge of that part only. Thus, a single questionnaire is not appropriate for all the users. The analyst must prepare different sets of questionnaires for different group of users. He should consider various issues while preparing questionnaires like the length of questionnaires, whether to ask close-ended or open-ended questions, and so on. Once the questionnaires are prepared, they are distributed to the users. In this method, users get sufficient time, which enables them to give correct answers of the queries.
9. On site observation: Generally, users are not able to express the process of how they work. Thus, to have a close look of the system, the analyst may decide to perform the site visit. Site visit enables the analyst to observe the current system, which helps him to detect the problems of existing system.
10. Prototypes: Prototypes help to clarify unclear requirements. Like scenarios, prototypes also help users to understand the information they need to provide to the software development team.
11. Quality function deployment (QFD): This deployment translates user requirements into technical requirements for the software. For this, QFD facilitates the development team to understand what is valuable to users so that quality can be maintained throughout software development. QFD identifies the following user requirements.
12. General requirements: These requirements describe the system objectives, which are determined by various requirements elicitation techniques. Examples of general requirements are graphical displays requested by users, specific software functions, and so on.
13. Expected requirements: These requirements are implicit to software as users consider them to be fundamental requirements, which will be accomplished in the software and hence do not express them. Examples of expected requirements are ease of software installation, ease of software and user interaction, and so on.
14. Unexpected requirements: These requirements specify the requirements that are beyond user expectations. These requirements are not requested by the user but if added to the software, they become an additional feature of the software. An example of unexpected requirements is to have word processing software with additional capabilities such as page layout capabilities along with the earlier features.

Feasibility is defined as the practical extent to which a project can be performed successfully. To evaluate feasibility, a feasibility study is performed, which determines whether the solution considered to accomplish the requirements is practical and workable in the software. Information such as resource availability, cost estimation for software development, benefits of the software to the organization after it is developed and cost to be incurred on its maintenance are considered during the feasibility study. The objective of the feasibility study is to establish the reasons for developing the software that is acceptable to users, adaptable to change and conformable to established standards. Various other objectives of feasibility study are listed below.

• To analyze whether the software will meet organizational requirements.

• To determine whether the software can be implemented using the current technology and within the specified budget and schedule.

• To determine whether the software can be integrated with other existing software.

Types of Feasibility

Various types of feasibility that are commonly considered include technical feasibility, operational feasibility, and economic feasibility.

Technical feasibility assesses the current resources (such as hardware and software) and technology, which are required to accomplish user requirements in the software within the allocated time and budget. For this, the software development team ascertains whether the current resources and technology can be upgraded or added in the software to accomplish specified user requirements. Technical feasibility also performs the following tasks. 

• Analyzes the technical skills and capabilities of the software development team members.

• Determines whether the relevant technology is stable and established.

• Ascertains that the technology chosen for software development has a large number of users so that they can be consulted when problems arise or improvements are required.

Operational feasibility assesses the extent to which the required software performs a series of steps to solve business problems and user requirements. This feasibility is dependent on human resources (software development team) and involves visualizing whether the software will operate after it is developed and be operative once it is installed. Operational feasibility also performs the following tasks.

• Determines whether the problems anticipated in user requirements are of high priority.

• Determines whether the solution suggested by the software development team is acceptable.

• Analyzes whether users will adapt to a new software.

• Determines whether the organization is satisfied by the alternative solutions proposed by the software development team.

Economic feasibility determines whether the required software is capable of generating financial gains for an organization. It involves the cost incurred on the software development team, estimated cost of hardware and software, cost of performing feasibility study, and so on. For this, it is essential to consider expenses made on purchases (such as hardware purchase) and activities required to carry out software development. In addition, it is necessary to consider the benefits that can be achieved by developing the software. Software is said to be economically feasible if it focuses on the issues listed below.

• Cost incurred on software development to produce long-term gains for an organization.

• Cost required to conduct full software investigation (such as requirements elicitation and requirements analysis).

• Cost of hardware, software, development team, and training.

Feasibility Study Process

Feasibility study comprises the following steps.

• Information assessment: Identifies information about whether the system helps in achieving the objectives of the organization. It also verifies that the system can be implemented using new technology and within the budget and whether the system can be integrated with the existing system.

• Information collection: Specifies the sources from where information about software can be obtained. Generally, these sources include users (who will operate the software), organization (where the software will be used), and the software development team (which understands user requirements and knows how to fulfill them in software).

• Report writing: Uses a feasibility report, which is the conclusion of the feasibility study by the software development team. It includes the recommendations whether the software development should continue. This report may also include information about changes in the software scope, budget, and schedule and suggestions of any requirements in the system.

• General information: Describes the purpose and scope of feasibility study. It also describes system overview, project references, acronyms and abbreviations, and points of contact to be used. System overview provides description about the name of the organization responsible for the software development, system name or title, system category, operational status, and so on. Project references provide a list of the references used to prepare this document such as documents relating to the project or previously developed documents that are related to the project. Acronyms and abbreviations provide a list of the terms that are used in this document along with their meanings. Points of contact provide a list of points of organizational contact with users for information and coordination. For example, users require assistance to solve problems (such as troubleshooting) and collect information such as contact number, e-mail address, and so on.

Management summary: Provides the following information.

• Environment: Identifies the individuals responsible for software development. It provides information about input and output requirements, processing requirements of the software and the interaction of the software with other software. It also identifies system security requirements and the system’s processing requirements

• Current functional procedures: Describes the current functional procedures of the existing system, whether automated or manual. It also includes the data-flow of the current system and the number of team members required to operate and maintain the software.

• Functional objective: Provides information about functions of the system such as new services, increased capacity, and so on. 

• Performance objective: Provides information about performance objectives such as reduced staff and equipment costs, increased processing speeds of software, and improved controls.

• Assumptions and constraints: Provides information about assumptions and constraints such as operational life of the proposed software, financial constraints, changing hardware, software and operating environment, and availability of information and sources.

• Methodology: Describes the methods that are applied to evaluate the proposed software in order to reach a feasible alternative. These methods include survey, modeling, benchmarking, etc.

• Evaluation criteria: Identifies criteria such as cost, priority, development time, and ease of system use, which are applicable for the development process to determine the most suitable system option.

• Recommendation: Describes a recommendation for the proposed system. This includes the delays and acceptable risks.

• Proposed software: Describes the overall concept of the system as well as the procedure to be used to meet user requirements. In addition, it provides information about improvements, time and resource costs, and impacts. Improvements are performed to enhance the functionality and performance of the existing software. Time and resource costs include the costs associated with software development from its requirements to its maintenance and staff training. Impacts describe the possibility of future happenings and include various types of impacts as listed below.

• Equipment impacts: Determine new equipment requirements and changes to be made in the currently available equipment requirements.

• Software impacts: Specify any additions or modifications required in the existing software and supporting software to adapt to the proposed software.

• Organizational impacts: Describe any changes in organization, staff and skills requirement.

• Operational impacts: Describe effects on operations such as user-operating procedures, data processing, data entry procedures, and so on.

• Developmental impacts: Specify developmental impacts such as resources required to develop databases, resources required to develop and test the software, and specific activities to be performed by users during software development.

• Security impacts: Describe security factors that may influence the development, design, and continued operation of the proposed software.

• Alternative systems: Provide description of alternative systems, which are considered in a feasibility study. This also describes the reasons for choosing a particular alternative system to develop the proposed software and the reason for rejecting alternative systems.

In the software development process, requirement phase is the first software engineering activity. This phase is a user-dominated phase and translates the ideas or views into a requirements document. Note that defining and documenting the user requirements in a concise and unambiguous manner is the first major step to achieve a high-quality product.

The requirement phase encompasses a set of tasks, which help to specify the impact of the software on the organization, customers’ needs, and how users will interact with the developed software. The requirements are the basis of the system design. If requirements are not correct the end product will also contain errors. Note that requirements activity like all other software engineering activities should be adapted to the needs of the process, the project, the product and the people involved in the activity. Also, the requirements should be specified at different levels of detail. This is because requirements are meant for people such as users, business managers, system engineers, and so on. For example, business managers are interested in knowing which features can be implemented within the allocated budget whereas end-users are interested in knowing how easy it is to use the features of software.

What is Software Requirement?

Requirement is a condition or capability possessed by the software or system component in order to solve a real world problem. The problems can be to automate a part of a system, to correct shortcomings of an existing system, to control a device, and so on. IEEE defines requirement as (1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. (3) A documented representation of a condition or capability as in (1) or (2).’

Requirements describe how a system should act, appear or perform. For this, when users request for software, they provide an approximation of what the new system should be capable of doing. Requirements differ from one user to another and from one business process to another.

Guidelines for Expressing Requirements

The purpose of the requirements document is to provide a basis for the mutual understanding between the users and the designers of the initial definition of the software development life cycle (SDLC) including the requirements, operating environment and development plan.

The requirements document should include the overview, the proposed methods and procedures, a summary of improvements, a summary of impacts, security, privacy, internal control considerations, cost considerations, and alternatives. The requirements section should state the functions required in the software in quantitative and qualitative terms and how these functions will satisfy the performance objectives. The requirements document should also specify the performance requirements such as accuracy, validation, timing, and flexibility. Inputs, outputs, and data characteristics need to be explained. Finally, the requirements document needs to describe the operating environment and provide (or make reference to) a development plan.

There is no standard method to express and document requirements. Requirements can be stated efficiently by the experience of knowledgeable individuals, observing past requirements, and by following guidelines. Guidelines act as an efficient method of expressing requirements, which also provide a basis for software development, system testing, and user satisfaction. The guidelines that are commonly followed to document requirements are listed below.

1. Sentences and paragraphs should be short and written in active voice. Also, proper grammar, spelling, and punctuation should be used.
2. Conjunctions such as ‘and’ and ‘or’ should be avoided as they indicate the combination of several requirements in one requirement.
3. Each requirement should be stated only once so that it does not create redundancy in the requirements specification document.

Types of Requirements

Requirements help to understand the behavior of a system, which is described by various tasks of the system. For example, some of the tasks of a system are to provide a response to input values, determine the state of data objects, and so on. Note that requirements are considered prior to the development of the software. The requirements, which are commonly considered, are classified into three categories, namely, functional requirements, non-functional requirements, and domain requirements.

IEEE defines functional requirements as ‘a function that a system or component must be able to perform.’ These requirements describe the interaction of software with its environment and specify the inputs, outputs, external interfaces, and the functions that should be included in the software. Also, the services provided byfunctional requirements specify the procedure by which the software should reactto particular inputs or behave in particular situations.

To understand functional requirements properly, let us consider the following example of an online banking system.

1. The user of the bank should be able to search the desired services from the available ones.
2. There should be appropriate documents’ for users to read. This implies that when a user wants to open an account in the bank, the forms must be available so that the user can open an account.
3. After registration, the user should be provided with a unique acknowledgement number so that he can later be given an account number.

The above mentioned functional requirements describe the specific services provided by the online banking system. These requirements indicate user requirements and specify that functional requirements may be described at different levels of detail in an online banking system. With the help of these functional requirements, users can easily view, search and download registration forms and other information about the bank. On the other hand, if requirements are not stated properly, they are misinterpreted by software engineers and user requirements are not met.

The functional requirements should be complete and consistent. Completeness implies that all the user requirements are defined. Consistency implies that all requirements are specified clearly without any contradictory definition. Generally, it is observed that completeness and consistency cannot be achieved in large software or in a complex system due to the problems that arise while defining the functional requirements of these systems. The different needs of stakeholders also prevent the achievement of completeness and consistency. Due to these reasons, requirements may not be obvious when they are,’first specified and may further lead to inconsistencies in the requirements specification.

The non-functional requirements (also known as quality requirements) are related to system attributes such as reliability and response time. Non-functional requirements arise due to user requirements, budget constraints, organizational policies, and so on. These requirements are not related directly to any particular function provided by the system.

Non-functional requirements should be accomplished in software to make it perform efficiently. For example, if an aeroplane is unable to fulfill reliability requirements, it is not approved for safe operation. Similarly, if a real time control system is ineffective in accomplishing non-functional requirements, the control functions cannot operate correctly.

The description of different types of non-functional requirements is listed below.

1. Product requirements: These requirements specify how software product performs. Product requirements comprise the following.
2. Efficiency requirements: Describe the extent to which the software makes optimal use of resources, the speed with which the system executes, and the memory it consumes for its operation. For example, the system should be able to operate at least three times faster than the existing system.
3. Reliability requirements: Describe the acceptable failure rate of the software. For example, the software should be able to operate even if a hazard occurs.
4. Portability requirements: Describe the ease with which the software can be transferred from one platform to another. For example, it should be easy to port the software to a different operating system without the need to redesign the entire software.
5. Usability requirements: Describe the ease with which users are able to operate the software. For example, the software should be able to provide access to functionality with fewer keystrokes and mouse clicks.
6. Organizational requirements: These requirements are derived from the policies and procedures of an organization. Organizational requirements comprise the following.
7. Delivery requirements: Specify when the software and its documentation are to be delivered to the user.
8. Implementation requirements: Describe requirements such as programming language and design method.
9. Standards requirements: Describe the process standards to be used during software development. For example, the software should be developed using standards specified by the ISO and IEEE standards.
10. External requirements: These requirements include all the requirements that affect the software or its development process externally. External requirements comprise the following.
11. Interoperability requirements: Define the way in which different computer based systems will interact with each other in one or more organizations.
12. Ethical requirements: Specify the rules and regulations of the software so that they are acceptable to users.
13. Legislative requirements: Ensure that the software operates within the legal jurisdiction. For example, pirated software should not be sold.

Non-functional requirements are difficult to verify. Hence, it is essential to write non-functional requirements quantitatively, so that they can be tested. For this, non-functional requirements metrics are used. These metrics are listed in Table.

                               Metrics for Non-functional Requirements

Requirements which are derived from the application domain of the system instead from the needs of the users are known as domain requirements. These requirements may be new functional requirements or specify a method to perform some particular computations. In addition, these requirements include any constraint that may be present in the existing functional requirements. As domain requirements reflect the fundamentals of the application domain, it is important to understand these requirements. Also, if these requirements are not fulfilled, it may be difficult to make .the system work as desired.

A system can include a number of domain requirements. For example, it may comprise a design constraint that describes the user interface, which is capable of accessing all the databases used in a system. It is important for a development team to create databases and interface designs as per established standards. Similarly, the requirements of the user such as copyright restrictions and security mechanism for the files and documents used in the system are also domain requirements. When domain requirements are not expressed clearly, it can result in the following difficulties.

Problem of understandability: When domain requirements are specified in the language of application domain (such as mathematical expressions), it becomes difficult for software engineers to understand them.

Problem of implicitness: When domain experts understand the domain requirements but do not express these requirements clearly, it may create a problem (due to incomplete information) for the development team to understand and implement the requirements in the system.

Requirements Engineering Process

This process is a series of activities that are performed in the requirements phase to express requirements in the Software Requirements Specification (SRS)document. It focuses on understanding the requirements and its type so that an appropriate technique is determined to carry out the Requirements Engineering (RE) process. The new software developed after collecting requirements either replaces the existing software or enhances its features and functionality. For example, the payment mode of the existing software can be changed from payment through hand-written cheques to electronic payment of bills.

An RE process is shown, which comprises various steps including feasibility study, requirements elicitation, requirements analysis, requirements specification, requirements validation, and requirements management.

The requirements engineering process begins with feasibility study of the requirements. Then requirements elicitation is performed, which focuses on gathering user requirements. After the requirements are gathered, an analysis is performed, which further leads to requirements specification. The output of this is stored in the form of software requirements specification document. Next, the requirements are checked for their completeness and correctness in requirements validation. Last of all, to understand and control changes to system requirements, requirements management is performed.

Quantitative Process Management (QPM) aims to control the process performance (the actual output accomplished by following the software process) of the software project quantitatively. The quantitative process management establishes goals for the performance of the project’s software process. It involves measuring the performance of software process, analyzing these measurements, and making adjustments in maintaining the performance of the process. After the performance of the process is stable and within acceptable limits, the software process of the project and the associated measurements are established as a baseline. This results in controlling the performance of the software process quantitatively. The goals of quantitative process management are listed below.

1. To plan the activities for quantitative management
2. To control the process performance of the project’s defined software process quantitatively
3. To identify the process capability of the organization standard software process in quantitative terms.

For QPM to work effectively and efficiently, various entry and exit criteria are defined. These, along with the tasks involved, are shown in Table.

                                       Table Quantitative Process Management

After the outputs from the tasks are available, verification is done on the following basis.

1. Reviews with senior management and project management
2. Reviews/audits by software quality assurance
3. Measurement of the status of QPM activities.

The organization follows a written policy for evaluating and quantitatively controlling the performance of the software process of the project. For this, various steps are followed, which are listed below.

1. Each project implements a documented plan to bring the software process of the project under a quantitative control. The quantitative control refers to the quantitative technique, which is appropriate to analyze the software processes. It identifies a specific condition or a specific group of individuals performing in an unexpected manner.
2. The sensitive data related to an individual’s performance is protected and access to this data is controlled. The measurement data is used to evaluate the individuals who intentionally affect the correctness and usefulness of the reported data.

Changes in the process are unavoidable and should be made to improve the productivity and quality of the process. These changes can be applied by using Process Change Management (PCM), which is a technique to improve the software processes in the organization. Thus, this technique helps in increasing productivity and quality by improving software processes for the developing software.

Process change management determines the process improvement goals, identifies, evaluates and implements improvements to the standard software process in the organization and defines software processes for the new projects to be developed. The organization follows a written policy for implementing software process improvements. The policy follows the steps listed below.

1. The organization has the quantitative and measurable goals to improve the software processes and tracks performance against these goals.

2. The organization’s process improvement is directed towards improving the quality, increasing productivity and decreasing the time for the development of the product.

3. The organization’s staff members participate in the process improvement.

Process improvement does not take place in a single stage; it is a continuous process which goes through different stages as listed in Table. The software process improvement activities are managed according to a documented procedure, which is maintained in the central repository. Review of the processes is conducted in a phased and structured manner to ensure that continuous process improvement activities are conducted and monitored.

                                           Table Process Improvement Stages

Training programs are established to enable and encourage individuals in the organization to participate in the process improvement activities. Improvement opportunities are identified and evaluated, which benefit the organization. When software process improvements are approved for general practice, the organization standard software process and the project-defined software processes are revised appropriately.

Software process change management follows a procedure for improving the software processes in the organization. This procedure specifies the following steps.

1. The improvement of the software process requires a proposal to be submitted, which includes the organization’s software process improvement goals and recommendations for software process assessment. In addition, it contains analysis of data on the performance of the project as compared to the quality of the software and the productivity goals.

2. The proposal is evaluated to ensure whether to implement it. The decision for implementing the proposal is then documented.

3. The benefits expected from the software process are determined. These benefits include quality of the product, end user satisfaction, and so on.

4. The priority of software process improvement proposals is determined, according to which selection for the implementation is made.

5. Implementation of the software process improvement actions resulting from the proposal is assigned and planned.

6. The actions for software process improvement, which require significant effort, are assigned to the team responsible for implementing the actions.

7. The status of each process improvement proposal is monitored.

8. Software process improvement proposals whose responses are unusually long are identified and acted upon.

9. The user reviews the changes before they are implemented, which are estimated to have an impact on the quality of the product.

10. When the actions of the software process improvement are completed, they are reviewed and verified.

11. The submitter of the software process improvement proposal receives acknowledgement of proposals and notification of the disposition. of the proposals.

When a decision is made to transfer software process improvement into general practice, the improvement is again implemented according to a documented procedure, which specifies the following steps.

1. The resources required to manage the changes in the software process are established.

2. The strategy to collect data for evaluating and monitoring changes in the performance of the software process is reviewed, agreed and documented. The individuals, who are implementing the software processes affected by the change, agree to this strategy. The support tools are instrumented accordingly to record the required data automatically.

3. Training is provided before installing the process change for general use. Training courses are updated to reflect the current software processes.

4. Appropriate process changes are incorporated into the organization’s standard software process and the project-defined software processes.

The Organization Process Focus (OPF) is responsible for establishing software process activities and improving these activities with process capability specified by the organization. This involves understanding software processes of projects and coordinating activities to assess, develop, maintain, and improve those processes. The organization provides resources for coordinating and maintaining software processes for existing and future projects. The activities for such purposes are carried out by SEPG. This group is responsible for developing and maintaining standard software processes and process assets in the organization. SEPG also coordinates process activities with the software projects. The goals of the organization process focus are listed below.

1. To coordinate software process development and improvement activities in the organization
2. To identify the strengths and weaknesses of the software processes according to the process standard
3. To plan organization level process development and improvement activities.

To coordinate software process development and improvement activities, the organization follows written policy. This policy follows certain steps, which are listed below.

1. A group responsible for organization-level, software process is established, which coordinates the processes with the projects.

2. The processes utilized by the projects are assessed to specify the strengths and weaknesses of these processes.

3. Software processes (used by the projects) are appropriately customized according to the standard software processes of the organization.

The senior management in the organization monitors software process development and activities to ensure that the standard software processes of the organization are according to its business strategies and goals. In addition, the senior management advises on setting priorities and participates in establishing plans for software process development and improvement.

The organization maintains a plan for improving the software process development and activities. It determines activities which are to be performed and a schedule for those activities. The plan specifies the resources, individuals and the tools required for improving the software process in the organization. In addition, when the plan is created, it is reviewed and accepted by the organization’s senior managers.

Organization Process Definition (OPD) is responsible for developing and maintaining a usable set of software process assets. The objective is to develop and maintain a standard software process for the organization. The organization process assets improve process performance across different projects and provide a basis for long term benefits to the organization. Various assets of the organization software process are listed below.

1. Organization standard software process
2. Guidelines and criteria for the projects
3. Descriptions of software development life cycles
4. Organization software process database
5. Central repository of software process related documentation, which is available for reuse.

Depending on the implementation of OPD, the software process asset is collected in the software process library. Other than assets, the software process library also includes the process item, which includes the tasks and activities for software processes. The software process for an organization is used in developing, implementing, and maintaining the projects defined in software processes. In organization process definition, the organization follows a written policy for developing and maintaining a standard software process and related process assets. Specifications of this policy are listed below.

1. Standard software process is defined for the organization and it can contain various other software processes. These software processes are essential to address the needs of different applications and tools that are included in the software projects.
2. Software process assets of the organization are maintained.
3. Information collected from the projects is organized and used to improve the organization standard software process.

The software process model framework is specific to the project. Thus, it is essential to select the software process model according to the software which is to be developed. The software project is considered efficient if the process model is selected according to the requirements. It is also essential to consider time and cost while choosing a process model as cost and/ or time constraints play an important role in software development. The basic characteristics required to select the process model are project type and associated risks, requirements of the project, and the users.

One of the key features of selecting a process model is to understand the project in terms of size, complexity, funds available, and so on. In addition, the risks which are associated with the project should also be considered. Note that only a few process models emphasize risk assessment. Various other issues related to the project and the risks are listed in Table.

Table Selections on the Basis of the Project Type and Associated Risks

The most essential feature of any process model is to understand the requirements of the project. In case the requirements are not clearly defined by the user or poorly understood by the developer, the developed software leads to ineffective systems. Thus, the requirements of the software should be clearly understood before selecting any process model. Various other issues related to the requirements are listed in Table.

              Table Selection on the Basis of the Requirements of the Project

Software is developed for the users. Hence, the users should be consulted while selecting the process model. The comprehensibility of the project increases if users are involved in selecting the process model. It is possible that a user is aware of the requirements or has a rough idea of the requirements. It is also possible that the user wants the project to be developed in a sequential manner or an incremental manner (where a part is delivered to the user for use). Various other issues related to the user’s satisfaction are listed in Table.

                                      Table Selection on the Basis of the Users

The formal methods model is concerned with the application of a mathematical technique to design and implement the software. This model lays the foundation for developing a complex system and supporting the program development. The formal methods used during the development process provide a mechanism for eliminating problems, which are difficult to overcome using other software process models. The software engineer creates formal specifications for this model. These methods minimize specification errors and this result in fewer errors when the user begins using the system.

Formal methods comprise formal specification using mathematics to specify the desired properties of the system. Formal specification is expressed in a language whose syntax and semantics are formally defined. This language comprises a syntax that defines specific notation used for specification representation; semantic, which uses objects to describe the system; and a set of relations, which uses rules to indicate the objects for satisfying the specification.

Generally, the formal method comprises two approaches, namely, property based and model-based. The property-based specification describes the operations performed on the system. In addition, it describes the relationship that exists among these operations. A property-based specification consists of two parts: signatures, which determine the syntax of operations and an equation, which defines the semantics of the operations through a set of equations known as axioms. The model-based specification utilizes the tools of set theory, function theory, and logic to develop an abstract model of the system. In addition, it specifies the operations performed on the abstract model. The model thus developed is of a high level and idealized. A model-based specification comprises a definition of the set of states of the system and definitions of the legal operations performed on the system to indicate how these legal operations change the current state.

Various advantages and disadvantages associated with a formal method model are listed in Table.

         Table Advantages and Disadvantages of Formal Methods Model

In the build and fix model (also referred to as an ad hoc model), the software is developed without any specification or design. An initial product is built, which is then repeatedly modified until it (software) satisfies the user. That is, the software is developed and delivered to the user. The user checks whether the desired functions ‘are present. If not, then the software is changed according to the needs by adding, modifying or deleting functions. This process goes on until the user feels that the software can be used productively. However, the lack of design requirements and repeated modifications result in loss of acceptability of software. Thus, software engineers are strongly discouraged from using this development approach.

This model includes the following two phases.

• Build: In this phase, the software code is developed and passed on to the next phase.
• Fix: In this phase, the code developed in the build phase is made error free. Also, in addition to the corrections to the code, the code is modified according to the user’s requirements.

Various advantages and disadvantages associated with the build and fix model are listed in Table.

              Table Advantages and Disadvantages of Build and Fix Model

The V model is useful in every phase of the software development life cycle. This model determines the complex relationship between each phase of the software development and ensures that each phase of software development is associated with testing. Various functions performed by V model are listed below.

1. It emphasizes that testing occurs in every phase of software development and does not occur only after the coding is completed.
2. It determines the software development process within the organization.
3. It determines the activities and the results to be produced in the software development.
4. It describes the products to be created during the software project.
   

The V model is divided into two branches: left and right. The left branch analyzes and determines the requirements of the software to be developed. The right branch, on the other hand, includes the testing activities. The left and right branches of this model work concurrently. This implies that a relationship is established between both the branches.

The interrelationship between the branches of V model can be determined by the following points.

1. Unit testing verifies the technical design. It individually tests units to verify that they (units) are functioning according to the requirements.
2. The integration and system testing verifies the functional design of the program, to ensure that the functional design is implemented correctly.

1. The requirements of the business are validated at the user end with the help of acceptance testing. Acceptance testing is used when the final software is developed. It verifies that the software has been developed according to the user’s requirements.
2. Last of all, the production verification is carried out.

One of the key aspects of the V model is that verification and validation are performed simultaneously in both the branches. It is essential to link the left branch with the right branch as the left side of V model is executed to correct problems, which are encountered during verification and validation (the right side).

Various advantages and disadvantages associated with the V model are listed in Table

                          Table Advantages and Disadvantages of V Model

The rapid application development model emphasizes on delivering projects in small pieces. If the project is large, it is divided into a series of smaller projects. Each of these smaller projects is planned and delivered individually. Thus, with a series of smaller projects, the final project is delivered quickly and in a less structured manner. The major characteristic of the RAD model is that it focuses on the reuse of code, processes, templates, and tools.

The phases of RAD model are listed below.

1. Planning: Inthis phase, the tasks and activities are planned. The derivables produced from this phase are project definition, project management procedures, and a work plan. Project definition determines and describes the project to be developed. Project management procedure describes processes for managing issues, scope, risk, communication, quality, and so on. Work plan describes the activities required for completing the project.

2. Analysis: The requirements are gathered at a high level instead of at the precise set of detailed requirements level. Incase the user changes the requirements, RAD allows changing these requirements over a period of time. This phase determines plans for testing, training and implementation processes. Generally, the RAD projects are small in size, due to which high-level strategy documents are avoided.

3. Prototyping: The requirements defined in the analysis phase are used to develop a prototype of the application. A final system is then developed with the help of the prototype. For this, it is essential to make decisions regarding technology and the tools required to develop the final system.

4. Repeat analysis and prototyping as necessary: When the prototype is developed, it is sent to the user for evaluating its functioning. After the modified requirements are available, the prototype is updated according to the new set of requirements and is again sent to the user for analysis.

5. Conclusion of prototyping: As a prototype is an iterative process, the project manager and user agree on a fixed number of processes. Ideally, three iterations are considered. After the third iteration, additional tasks for developing the software are performed and then tested. Last of all, the tested software is implemented.
6. Implementation: The developed software, which is fully functioning, is deployed at the user’s end.
   

Various advantages and disadvantages associated with the RAD model are listed in Table.

                     Table Advantages and Disadvantages of RAD Model

In time boxing model, development is done iteratively as in the iterative enhancement model. However, in time boxing model, each iteration is done in a timebox of fixed duration. The functionality to be developed is adjusted to fit the duration of the timebox. Moreover, each timebox is divided into a sequence of fixed stages where each stage performs a clearly defined task (analysis, implementation, and deploy) that can be done independently. This model also requires that the time duration of each stage is approximately equal so that pipelining concept is employed to have the reduction in development time and product releases.

There is a dedicated team for each stage so that the work can be done in pipelining. Thus, stages should be chosen in such a way that each stage perform some logical unit of work that becomes the input for next stage.

In addition to the advantages of iterative model, time boxing model has some other advantages too. Various advantages and disadvantages associated with timeboxing model are listed in Table.

          Table Advantages and Disadvantages of the Time boxing Model

The incremental model (also known as iterative enhancement model) comprises the features of waterfall model in an iterative manner. The waterfall model performs each phase for developing complete software whereas the incremental model has phases similar to the linear sequential model arid has an iterative nature of prototyping. During the implementation phase, the project is divided into small subsets known as increments that are implemented individually. This model comprises several phases where each phase produces an increment. These increments are identified in the beginning of the development process and the entire process from requirements gathering to delivery of the product is carried out for each increment. [Read more…] about Incremental Model or iterative enhancement model in software engineering