Establishing Top-Level Requirements

There are several different categories of requirements. Some requirements comply with the specific operational needs of the customer, while others involve general system behavior, performance, and design. The best practice to successfully implementating and integrating new systems is to compile requirements in a ‘Top Down’ fashion. At the top will be the high-level business requirements, which will be expanded upon in each step till we get to the most granular technical requirements at the bottom. Eliciting feedback from clients and critical synthesis of the feedback helps formulate top level business requirements. This process is needed to accurately capture, interpret, and represent the customers’ voice when specifying requirements for a system or a problem. 

Client Interaction and Eliciting Requirements

Before constructing requirements, initial market research of the client company’s current systems and programs will give developers a basic idea of their business procedures and priorities. Preparedness and organization affects the relationship with the client and serves as the foundation of the project. 

More personal interactions with the client help to obtain a detailed understanding of their system needs. Frequent communication throughout the process will result in well-written requirements that both meet and exceed their expectations. Determining requirements involves analyzing the information collected from research and client interactions to define system problems, major stakeholders, and system goals. There are different methods of eliciting requirements, such as model-based techniques that apply a model to present functions and scenarios or contextual techniques that focus primarily on user feedback and observation. Any approach to eliciting requirements depends on the time, resources available, and type of information collected. Acknowledging the challenges as well as creating a standardized Top-Level Requirements document will ensure the customer’s perspectives are incorporated into product design. Undergoing this process will guarantee that all stakeholders are on the same page when developing a solution, and in the end, leave all parties satisfied with the deliverable.

Modeling and Analysis

Modeling techniques represent system operations based on social and organizational contexts. There are several approaches to modeling such as enterprise modeling, data modeling, behavior modeling, and domain modeling that provide different methods of high-level analysis and reasoning for requirements specification:

• Enterprise Modeling – Focuses on the organization’s operations which include internal functions, employee roles and responsibilities, and the information collected. 
• Data Modeling – Involves the use of diagrams to map data flow in a complex software system. An example is Entity-Relationship-Attribute modeling which is a type of high-level data modelling applied in database design.
• Behavior Modeling – Concentrates on functionality and analyzes the current system in place to decide how the new system should be implemented.
• Domain Modeling – Provides a model environment in which the system may operate which assesses various interactions and relationships within the domain.
• Non-Functional Requirements Modeling – Non-Functional Requirements are concerned with usability and overall operations as opposed to individual functions. Analyzing non-functional requirements can be a challenge because these requirements aim to measure the quality of the entire system. Technological researchers continue to test methods for measuring non-functional requirements through diagram or illustration-based models.

Models not only represent functionality, but the overall environment in which the system will operate. Models and case studies are valuable in assessing cost, risk, and effectiveness of requirements. This analysis is vital for tracking system progress and making appropriate and effective changes. 

Communication and Requirement Management

The communication and management phase follows modeling and analysis to ensure that requirements are readable, accurate, and consistent. It is important to have a high-level understanding of system requirements and to be able to express the information at both high and lower level languages to involve all major stakeholders in the conversation. There is no single method of structuring requirements documents. The standards for documentation depend on communication between the client and engineer as well as the context of the system itself (i.e. How it will be used). Readability is imperative to managing progress, making changes, and evolving requirements over time.

Validation and Review

It is important to confirm that all stakeholders agree with the specified requirements and that these requirements align with their original requests. Conflicting views between stakeholders can pose a major problem in this stage. All stakeholders in a project, including end users, software managers, and customer managers, must achieve a common understanding of the product and what it will do. If this unifying knowledge between stakeholders is not established, it is likely that one party will be displeased. Professional discussions with all stakeholders can help bring them to a compromise.

Requirements should also be checked once again for consistency and completeness. Poorly written requirements can be misread or exclude major components that affect the quality of the system. If the requirements document is readable, accurate, and consistent early on, then the reviewal phase will be easier to accomplish. 

Logapps Automated Requirements Analysis

Logapps has demonstrated customer-driven values and an innovative spirit by applying a Function Point Automation (FPA) tool to facilitate requirements analysis. This tool produces consistent and immediate function point estimates, delivers software development cost and effort estimates, provides a comprehensive view of the system, identifies duplicate and similar requirements, and detects poorly written or vague requirements (read our blog post about Requirements Analysis Through Function Point Automationto learn more). FPA makes requirements analysis much more efficient for the software developer as opposed to the complex manual process that requires hundreds of human work hours. 

Logapps is dedicated to providing high quality consulting and technological development services to its clients. Continuous effort towards research and systems improvement in requirements engineering gives us an edge that separates us from our competitors. By transitioning to automated technologies, Logapps developers can spend less time performing tedious data analysis tasks, and more time fulfilling client needs and goals.

References

Nuseibeh, Bashar and Easterbrook, Steve. “Requirements Engineering: A Roadmap”. Proceedings of the Conference on the Future of Software Engineering, pp. 35–46., http://mcs.open.ac.uk/ban25/papers/sotar.re.pdf.