The Software Specifications are defined and data models created to ensure they meet the client’s requirements. These specifications provide a critical foundation for the design and implementation of the application.
During the Analysis Phase of the Systems Development Life Cycle, the client’s business requirements are analyzed further in order to build upon the statement of scope. The client is consulted and many questions are posed in order to ascertain the business rules of the organization in an effort to further refine the requirements. A business rule is a statement that defines or constrains some aspect of the business and is drawn from the various policies, events, procedures and functions of an organization. A business rule can be broken down into two points of view: a business constraint and an information system constraint. A business constraint involves a constraint on the action of employees in a particular division within an organization such as the procedures for properly finalizing a Request For Proposal. An information system constraint is a constraint on the storage of data, such as precisely what type of data is allowed to be recorded on an information system (Guide Business Rules Project, 1997).
It is critical that the client’s business rules be defined because they determine how data will be processed and stored. It is the role of the Yacoset software engineer then to document and structure those refined requirements and review them with the client.
In the real world, most users are not software engineers or computer programmers and may not know how to convert their needs into software specifications or terms. It is the role of the software engineer to effectively communicate with the client (in common, plain language) and analyze his or her business requirements, to ask questions, pose scenarios, and provide solutions. During Analysis, the software engineer works closely with the client in order to experience and understand the business for which the program will be engineered.
Critical to the construction of an application that meets the customer’s needs, software engineers must have knowledge that extends beyond computer science. A software engineer/computer scientist who is disciplined in other arenas (either experiential or academic), including business, management, finance, science, biology, social science, English, history or, yes, even art, can help the customer more effectively meet his or her ends. Skills and knowledge in other disciplines applied in conjunction with an expertise in software engineering provides each customer with the assurance that the engineer will understand and recognize his or her needs, provide insight, ask specialized questions relevant to the stated goals, and translate the customer’s vision into a design from which a high-quality software application can be constructed.
Prototypes are used to simulate some aspect of the program. Typically, paper prototypes are used to graphically represent an interface that will be part of the user experience. The client and users are given a set of questions and asked to take particular steps using the paper prototypes. This process allows engineers to analyze the usability and functionality of the system so changes can be made to better fit those needs. It is much simpler to modify a paper prototype than a nearly complete program. Paper prototyping helps isolate and remedy potential problems early in the life cycle, which expedites the completion of the system. Although paper prototyping is most common, sometimes it is necessary to build small versions of a functioning program so a client and users can gain first-hand interactive experience with some part of the program. This is called a working prototype.
Determining the customer’s business rules allows the Yacoset software engineers to develop data models, a process known as data modeling. By collecting the client’s business rules, which consist of the various procedures and functions of the business as well as entities of the business and its constraints that may impact the data or the software, an Entity-Relationship model can be constructed. The Entity-Relationship Model is used to graphically depict a conceptual structure of the business’s data and is arguably the most important aspect of the software development process. It defines the entities (or objects) of the required information system based on the relationships among, and the properties of, those entities. With the E-R model, our engineers are able to accurately model real-world situations of a business in a graphical format that is easy to read and understand.
From the refinement of scope, a top-down approach is used to organize the information system into a hierarchical and logical model.
Data Flow Diagrams (or DFDs) are created for various elements of the information system as well. Data Flow Diagrams represent the flow of data graphically and are used to depict the entire information system as well as individual components of the system. DFDs allow the analyst and the client to easily distinguish both the functionality and data flow of a system that further set the foundation for the design and eventual implementation of the application. Data Flow Diagrams can act as a complement to the E-R model in the identification of the flow of a system and the processing and storage of data.
Once the statement of scope has been refined, the business rules defined, and Entity-Relationship models and Data Flow Diagrams created, classes of tests are constructed that form the basis for later application testing. Classes of tests cover the overall testing strategy for the application and specify the order in which functionality and processing testing will be performed during and after the program is coded. It is from this overall testing strategy that distinct and comprehensive test cases will be formulated as the development cycle progresses.
The Analysis Phase results in Software Specifications, which include a complete description and detailing of the software, its functions, processes, requirements, design constraints and test classes. The following is an outline of the Software Specification document (adapted from IEEE Standard 830-1998):
Software Specifications
1. Introduction
1.1 Purpose
1.2 Business Objectives and Goals
1.3 Document conventions
1.4 Intended audience
1.5 Additional information
2. Software Description
2.1 Product perspective
2.2 Product functions
2.3 User classes and characteristics
2.4 Operating environment
2.5 User environment
2.6 Design and implementation constraints
2.7 Assumptions and dependencies
2.8 Data Flow Diagrams
2.9 Supporting Diagrams
3. Database Description
3.1 Business Rules
3.2 Entity-Relationship Models
4. External Interface Requirements
4.1 User interfaces
4.2 Hardware interfaces
4.3 Software interfaces
4.4 Communication protocols and interfaces
5. System Features
5.1 System feature A
5.1.1 Description and priority
5.1.2 Action and Result
5.1.3 Functional requirements
5.2 System feature B…
6. Validation Criteria
6.1 Testing Strategies
6.2 Testing Classes
7. Nonfunctional Requirements
7.1 Performance requirements
7.2 Safety requirements
7.3 Security requirements
7.4 Software quality attributes
7.5 Project documentation
7.6 User documentation
8. Other Requirements
9. Appendix A
9.1 Bibliography
10. Appendix B
10.1 Glossary
The Software Specifications are reviewed thoroughly with the client to answer questions and ensure that the specifications meet the customer’s expectations and requirements. At this stage, changes can be easily made and refinement performed to ensure that the specifications meet the client’s needs. Once the Software Specifications are finalized, they will serve as a solid foundation for the design and implementation of the program.