subject: Software System Development - a Proposal and Concept for better Development by Effective Requirement Engineering [print this page] Software System Development - a Proposal and Concept for better Development by Effective Requirement Engineering
Software System Development A Proposal
This article analyzes a company's existing Software System and proposes a concept to develop a better Software System.
I worked for a company where my job responsibility was to develop a new software system based on an existing software system. Based on my experience, I have discussed some methodology, procedures and examined some concept to develop a better software system. I am open to constructive suggestions and useful advice regarding the concept that I have discussed in this article.
1. Foundation:
The company has an existing Sales and Distribution System which is being used by the department. When the system was developed, there was not any proper documentation and Software Engineering process was not followed properly. And as a result design was poor and the solution is slow. The data model was not so effective. And the developers who developed the existing system are out of company and as a result the maintenance is difficult since lack of documents. Along with the design problems, the solution is developed in old technologies and technique like heavy weight data structure was used in the application layer. The information domain that was designed by the former developers do not meets the acceptance criteria of the users. As a result, many tables in the database are out of data. A user of the system is asking for a new user friendly Sales and Distribution System which they can use without any prior training. From the experience of the existing system, the developers have decided to set a development goal for their future Sales Operation.
2. Development Goal:
The goal is to develop a brand new, reliable, maintainable, reusable cost effective Sales and Distribution module to optimize the sales process where the basis will be analyzing the existing sales & Distribution module. The development goal is to emphasize in the Requirement elicitation, Analysis, Model, Specification and validation.
3. Development Objectives:
The objectives of the proposed software development are:
To make the sales process fast and efficient by developing a Model Sales and Distribution module where the system will meet all the features and functionality being performed in the company's Sales and Distribution process.
To add new features to make the process more effective.
To make extreme User involvement in the Development Life Cycle.
To ensure quality control. Quality Function Deployment (QFD) should be used to elicit requirements. "House of Quality" and "Voice of Customer" methods should be established.
To ensure that the Analyst, Developer and User s meet regularly.
To track the requirements properly.
To emphasize the Security requirements.
To document functionality, Information and behavior of the system prior to development.
To make the Data Architecture faster at data processing.
To make the User Interface simpler by making the decomposition of the existing Interfaces means by breaking the functionality of one Interface into multiple ones where Navigation between interfaces must be user friendly by using Evolutionary Prototype.
To use latest technologies and methods.
4. Concept to fulfill the Development Objectives:
If we consider the Sales and Distribution System as a product, we need to follow the concept of Product Engineering. Here the goal of Product Engineering will be to develop a working product that will meet all the Customer needs and the customer's desire will be focused in the Product. The world view of the Product Engineering will be achieved by Requirement Engineering. The world view means the capability of the working Product. The System Engineer will do the System Requirement Engineering and will develop the System Requirement Specification. In Product Engineering there are four System Components. They are Software, Hardware, Data and People. When the System Requirement Specification is made, the job of the System Engineer is to assign necessary function and behavior to the specific System Component. When the allocation is finished, then the individual Component Engineering starts. So, Software Engineering will be done for the System Component Software'. In this article we will focus on the Concepts of Requirement Eliciting, Analysis, Model, Specification and validation which is the elements of Software Requirement Engineering in the Software Engineering Discipline.
In the case of my company, the System Engineering has been done but not properly documented at the time of previous System development. Based on that System role has been allocated to the System Components. My discussion topic is in the role of Software and the concept that I will focus is in the Software Requirement Engineering phase of the Software Engineering. Here I will say what concept should be followed to develop an effective Software Requirement Specification.
4.1. Requirement Elicitation:
Before the Requirements can be analyzed, modeled and specified, the requirements should be gathered by the elicitation process. In the Requirement Elicitation step, we should follow a plan. Since there is an existing system working, we should analyze the existing system. So, one source of requirements can be the existing system's Software User Interface. Existing System's Informational domain by examining the Database can be a source of requirements. We should also gather requirements by the behavior of the existing system. We should find out the security requirements or constrains by reviewing the existing system. So, from the existing system we can get a rough idea on the requirements and the developers and analysts can have a basic knowledge base on the System that is going to be built.
One thing we should keep in mind that the early the requirement problem is found, it is easier to fix. So we should find the requirement problems at the time of documenting in the Requirement Engineering Process. Since the existing System is the primary source of requirements, we should keep ourselves busy in finding the existing requirement problems.
Secondly, we should gather requirements from the business experts and users of the existing System. Firstly we should make a list of all Stakeholders of the Desired System. The main source of the stake holders are the Developers, Users and the Customer. Here the users are the end users of the System and the Customers are the management stuff who has asked for the Software for their department. We should make an extreme user involvement in the development process. We should go to the right person to gather requirements means the right stakeholders should be identified. In, the Requirement Eliciting meeting the Customers will say what they want' and what they need'. From this point the developers will be confident that they are solving the right problem. Since the basic requirements are identified from the existing system, the negotiation should be to the refinement of the existing Requirements and the problems of the System. In the Requirement Elicitation Process no single user has the complete view of requirements rather they have own requirements in a particular situations. So, user involvement is necessary in the Elicitation Process. Effective Communication process should be established in the negotiation phase. It should be noted that User participation is the determinant of System Success.
Quality Function Deployment (QFD) is a formal technique used at the time of elicitation which helps to develop the specification. Researchers have found that this technique provides a better customer satisfaction. QFD aims to listen carefully the customer needs and provide a useful solution to the customer. According to Herzwurm [5] QFD "bridges a gap in the software development process to the customer. This is done using a systematic procedure for teamwork and the ability to prioritize all information concerning product development in a justified way".
"House of Quality" is a tool, used in QFD links the "voice of customer" with the design decisions. This means the tools make a list of customer "what's" in one column vertically and in the next column specifies the tasks how the customer what will be implemented. At the roof of "House of Quality" is the discussion in the meeting to assist feasibility and changes that need to be done in the specification document.
Let me discuss some tips which should follow in the Requirement Engineering process. They are that the requirements should be structured; the requirements should be testable, reusable requirements should be identified, source of the requirements should be maintained, along with functional requirements, all non functional requirements or the constraints should be identified.
4.2. Requirement Analysis, Modeling and Validation:
Requirement Analysis will provide the bridge between the System Level Engineering and the Software Design. This means Requirement Analysis will provide the detail "what" of the software that will be built. Software Engineer will design the software by getting information from Specification that the Requirement Engineer will provide at the time of Software Requirement Analysis. Roger Pressman states that,
"Requirements analysis provides the software designer with a representation of information, function, and behavior that can be translated to data, architectural, interface, and component-level designs."
Once the Software Requirement Specification has been made at the time of Requirement Analysis, the Specification will be used to asses for quality when the Software is built.
In case of my Company, the elicited requirements should be analyzed at this stage. By examining the existing Informational domain and the new elicited information domain, we can get a picture of the functionality of the Software. All the observable data objects should be listed. We should find out the flow of the information or content of the data objects and the behavior of the System that is the processing that happens by external or internal events. All analysis methods are related by a set of operational principles [1]:
The information domain of a problem must be represented and understood.
The functions that the software is to perform must be defined.
The behavior of the software (as a consequence of external events) must be Represented.
The models that depict information, function, and behavior must be partitioned In a manner that uncovers detail in a layered (or hierarchical) fashion.
The analysis process should move from essential information toward implementation Detail.
At the beginning of the Analysis phase, the process starts at Step one by creating an analysis team where the team member's skills are assessed, project environment is created. In the second step of the analysis phase is to determine the business requirements and find out the functional requirements. This step is done by techniques like JAD sessions, Interviewing, Storyboarding, Use case diagramming, Data flow diagramming, Prototyping; Walk through, Problem recognition, Structured English, Pseudo coding etc.
In the third step of the analysis process, we have to determine the process model. The techniques used are creating the Work flow diagram, Flow chat diagramming, Use case diagramming, Decision trees, Customer Events diagramming, Prototyping etc. The process model is developed at this stage. In the forth step Logical Data Model is developed. The techniques used are ER Diagramming, Data Normalization, and Denormalization etc.
In the fifth step of the Analysis process is to review the documents of the previous steps. All the derived requirements are assessed at this stage. One thing we have to remember that the requirements that are derived at this stage must be testable. That is we should specify the requirements in structured English like specifying "The system will perform .." or "The User will be notified by the System " I mean that the functional requirements must be validated by the User by some Validation Criteria when the System is built.
At the end of fifth step is to document the Software Requirement Specification. In the document the functional Specification's logic is expressed by pseudo code, structured English and object oriented logic. Let me give a list of contents that a model Software Requirement Specification will contain.
List of Contents and their Descriptions for Software Requirement Specification
Content Name: Goal and Objective
Reference Document: Software Scope in the Planning Document
Description: Something more than Scope is documented.
Content Name: Information Description
Reference Document: Documents of Step 4
Description: Information Content, Flow and Structure are documented.
Content Name: Functional Description
Reference Document: Documents of Step2 and Step 3
Description: A processing narrative is provided for each function, design constraints are stated and justified, performance characteristics are stated, and one or more diagrams are included to graphically represent the overall structure of the software and interplay among software functions and other system elements. Everything is documented.
Content Name: Behavioral Description
Reference Document: Documents of Step 4
Description: The operation of the software
As a consequence of external events and internally generated control characteristics are documented.
Content Name: Validation Criteria
Reference Document: Documents of Step 5
Description: Validation Criteria must be documented for assessing Quality. Function, Performance and Constrains must be validated.
Content Name: Bibliography and Appendix
Reference Document: Supporting Documents of all Steps
Description: The bibliography Contains references to all documents that relate to the software. These include other Software engineering documentation, technical references, vendor literature, and standards.
5. Recommendations:
In some cases it is possible that operational principles can be applied using the Analysis process discussed above and build a Software Model and then move to the Design Phase of the Software Development Life Cycle using the Software Model's Work product which is the Software Requirement Specification. Again in other situations it is possible to use QFD for requirement Elicitation, then operational analysis principles are applied and a model of software called Prototype is build for customer and developer assessment and then move to construction of the production Software.
In case of the Company of this article, they are using an existing Sales and Distribution System. They are using the System for five years but for the lacking of proper documentation in the Software Requirement Engineering, High Level Design, Low Level Design the Software is hard for maintenance. Since proper Software Engineering Process was not followed, results a poor design. But the software is running live and the department's basic objective is fulfilled with performance lack. My recommendation is that, we can get all the basic and expected requirements from the existing System and find out the exciting requirements by QFD. Then apply the operational analysis principles and develop a software model called Prototyping and move to the design phase.
References:
1. Software Engineering,FIFTH EDITION, Roger S. Pressman, Ph.D.
2. Global Knowledge, Expert Reference Series of White Papers, Richard Frederick, PMP, MCP, MSF Practitioner, IT Portfolio Manager, 1-800-COURSES, www.globalknowledge.com
3. USERS' INVOLVEMENT IN THE REQUIREMENTS ENGINEERING PROCESS, Daniela Elena Herlea
Knowledge Science Institute ,University of Calgary ,Calgary, Alberta, Canada T2N 1N4, danah@cpsc.ucalgary.ca
4. Domain focused requirements engineering: A case study of successful requirements engineering in a market-oriented automotive software development company, Irene Caulfield, Norah Power Lero, University of Limerick, Ireland, E-mail: irene.caulfield@lero.ie, norah.power@lero.ie
5. Herzwurm, G., S. Schockert, and P. Wolfram. QFD for Customer-Focused Requirements Engineering. In Proceedings of 11th International Requirements Engineering Conference. 2003: IEEE.
6. Ten steps to better requirements management. Dominic Tavassoli, IBM
7. Section III:2 System Requirements Analysis NYS Project Management Guidebook
