2.2 Requirements 

Previous | Next

In application development lifecycle, requirements literally means: the functional and non-functional needs of the business. These needs become the goals for the application development team. Requirements are the most critical factor in the success of any application development project for one simple reason: it defines what is required by the business to address it needs. It is important to define, communicate, and understand the requirements exactly the way it is supposed to be meant. Any ambiguity wording, misinterpretation, or missing information associated with requirements it results into non-conformance to requirements. Any lapse in the requirement phase that goes undetected can cost you more to rectify this at later stage. It impacts all critical parameters (quality, efforts, and schedule) that define the success or failure of the application development project.

Domino application development generally has a short duration of application development cycle. Considering Domino being a rapid application development platform, it leads to a common issue that the development teams do not allocate sufficient time and attention necessary to manage the requirements appropriately.  

In this section we discuss the best approach about requirement management, gathering, and prioritization.

Requirement management

 
Requirements are discussed and defined during the requirement phase and it continues to refine over the period of application lifecycle. The requirements and its degree of details vary depend on the awareness of the problem and benefit to gain by resolving the problem. The requirements origin is the problem statement, which is the purpose to formulate the requirements to address that problem. Business envisions the benefits of solving an existing problem or altogether innovates its existing process to achieve a competitive advantage. The purpose of requirement management is to organize the requirement, document it, verify that the requirement to ensure it meet the needs and expectation of the business and the stakeholders involved. To understand the requirements, a holistic approach has to be adapted, a proper consideration to be made to identify the functional and non-functional requirements.

A functional requirement is the primary functional features that the business expects from the proposed system to perform to address the specific problem. For example:
The product quality application must allow only the users from quality audit team to submit a quality audit report.   

The following are some of the common of functional requirement items: 

• Data input, output, and processing behavior: Such as the data input and output screens, data format, and data processing.
• Business rules and logic: Such as the task to be performed, data validation, data calculation, and data processes.
• Workflow requirements: Such as the application workflow, level of workflow, document routing, and mailing features.
• Interfaces with other system: Such as payment voucher to be generate using remote function call to a financial database.
• Security requirements: Such as document deletion access is only possible to a specific role.
• Reports or views: The data extraction based on query and representation in desired format.
• User roles and responsibilities: Such as a delegate person has option to make approval decision in absence of a primary approver.
• Error handling: Such as in event of failure to generate the payment voucher, how the order processing should be terminated, and how the log to be generated. 

 
A non-functional requirement is the requirement that enhance the functional requirements. Generally, it means the proposed system compliance with the constraints defined by the business. For example:
The new member added to the quality audit team, must be able to use the system within 4 hours of users enrolment in the audit team.   

The following are some of the common non-functional requirement items:

• Systems performance constraints: Such as the form load, refresh, or submission time.
• System security constraints: Such as restriction of directory listing, user authorization, data security. 
• User interface constraints: Such as GUI screen layout, formatting, and color themes.
• Maintainability: Ease of maintenance of the proposed system. For example, ease of adding a new page to the system, ease to change color themes or static text such as label, ease to add new level of workflow.
• Usability: System usability. For example, system to be accessible using browser client, mobile, thick client.
• Availability: System availability constraints. For example, system to be available 24x7 for the user access.
• Compatibility: System compatibility constraints. For example, cross-browser compatibility, multiple operating system platform.
• Internationalization: System portability to manage users from different locale and time zone. For example, system to support multiple languages and multiple time zone.
• Statutory constraints: The statutory or legal requirements. For example, enforce data access policy, audit trail for edit history.
• Hardware constraints: Systems ability to function within the limit of hardware constrains. For example, system to run at optimum level with 1 GB RAM.
• External Interfaces: System ability to integrate with external sources. For example, interface with Oracle, SAP, and third party tool.
• Operations: Systems compatibility with business operations constraints. For example, possibility for hot or cold system backup.

A good set of requirements have the following characteristics: 

• Correct: All requirements should tie back to a customer need.
• Unambiguous: A requirement should have only a single interpretation.
• Complete: All significant needs of users should be addressed.
• Consistent: There should not be any conflict within individual requirements.
• Ranked for importance: Ranking helps the team to address the most critical requirements first and to balance the resources to meet project objectives.  
• Verifiable: A person should be able to determine that the developed software meets the requirement.
• Traceable: It should be possible to trace a components requirement to its source 
• Understandable: The user and developer community should be able to comprehend the complete set of individual requirements and the aggregate set implied by the document.  

  
Best practices
Consider the following for requirements management:

• Separate each requirement point as an individual item to maintain a good level of requirement granularity.
• Assign number references to each requirement point and arrange them in the logical order of the flow of requirements as per the dependency on other requirements.
• As the requirement phase progress, keep requirement document updated with the renewed understanding after the interaction and query resolution activities with the stakeholder.
• Each requirement point should focus on a certain aspect. Elaborate each requirement point to a level until it is clear and no ambiguity. If other points come out as a result of elaboration, separate out those individual requirement points.
• Document the requirement in a simple and unambiguous manner, each requirement has to be unique and avoid duplication. It should be testable or verifiable during the testing phase.
• Maintain the requirement document versions regularly to keep the history of requirements evolution from the beginning. This helps to trace the origin of the requirement and every change or refinement done to the requirement. It also helps in maintaining the relationship between the requirements and their solutions.
• Plan a discussion at regular intervals with all the stakeholders to verify that the requirements are in line with the expectations by the business.
  • Identify risks and appropriate mitigation action and update the requirement document accordingly.
• In case of the requirement is complete for the enhancement of an existing system, the appropriate functional and technical impact analysis must be done. 
  • Identify the regression test scenario after discussion with business, while you develop the requirement document for such cases.

Requirement gathering

 
Requirement gathering is a subphase of the requirement phase. In the requirement gathering phase, you identify the stakeholders, the requirement owners, from whom the requirement must be gathered. It is possible to have multiple sources for requirements when the proposed solution spans over more than one workgroup in an organization.  You might given a draft requirement document or a simply a problem statement with expected benefits as the initial input from the stakehoders. On the basis of this, you have to gather, elicit, and engage interactions with the requirement owners to refine the raw requirements into meaningful and unambiguous requirement information. 

Technology is never a focus during the requirement phase. Assume that a business wants to leverage the existing investment in the Domino infrastructure. They intend to build some capabilities using the rapid application development platform of Domino. Below are some of the requirement gathering phases specific questionnaire for the Domino application development team:

• What are the problems to be solved by the proposed solution?
• What are the historical background of the problems?
• What is the scope of the proposed solution? What are included and excluded from the proposed solution?
• Are there any new problems the proposed solution could cause in the current system?
• Which are the locations the customers use the application? Are there any internationalization requirements?
• What are the security requirements and statutory constraints for the proposed solution?
• What are the access rights for the various users with respect to the application?
• Is there a need for data consistency checks and activity logging?
• What is the initial number of users for the proposed solution?
• What are the possible unknown factors and assumptions?
• What are the standards of performance or other quality attributes, which must be matched or exceeded in the proposed solution?
• What system behaviors do the customer consider as a defect in the system?
• Who are the users and the categories of users if any?
• Are there any technical feasibility issue in addressing a particular requirement?

In case of doubt, do a feasibility study or better do prototype to understand business expectation properly.

• Are there any third party components or commercial components to be integrated with Domino application?
• Are there any interfaces to the external data source system, such as RDBMS, web services, Microsoft Office components? What are the expected system response times from external interfaces?
• Is there any data that must be shared across applications?
• What are the hardware limitations that could constrain the design options?
• Are there any compliance constrains for the solution design to adhere some design or programming standards of the client?
• Are rich GUI features required? for example, drag and drop, multiple pop-ups, charts, dynamic data refresh.
• Are there any customer standards or guidelines to be complied with while designing the user interface?
• Will the customer provide screen layouts, graphics, GUI details such as font style, size, and color?
• Does the customer expect a prototype? Does the customer understand that the prototype will be purely navigational and will not be functional?
• Will the user provide the common messages to be thrown up by the application? 
  • Will the messages be classified into information, warning, and error messages?
  • Will the information messages be made configurable for the business to manage message text?
• What are the reports requirements the proposed solution has to provide? 
  • What are the purpose, intended audience, layout, and the source of data for each report?
  • Are sample report layouts available?
• For each item of input and output, What are the formats of data?
• What are the business rules and validations associated with each user task?
• Is the proposed solution to be available for usage on web browser, notes client, mobile, or a mix of different platforms?
• What are the requirements regarding compatibility? (for example, backwards, cross browser, and so on) 
• Are there any constraints around the operating or development environment? 
• What are the internationalization and localization requirements?
• Which are the different geographical regions, languages, and currencies that must be supported?
• Input format differences (for example, date, time, and currency) from display formats if any?
• In which format must the system store the information?
• What is the expected peak usage in terms of the maximum number of concurrent users?
• Is the number of users or size of transaction expected to grow in the future?
• What is the volume or size of data to be stored and handled by system?
• What are the intended major features that will probably provide the most value, at least cost, to the largest community of users, and this information to be used in requirement prioritization?

Query register sheet
It is often that the requirements or the problem statement defined by the business is not detailed, lacks clarity, and needs clarifications from the business. The development project team has to allocate sufficient time for clarifying the requirements in the requirement phase. The clarifying action continues, though less frequent, throughout the application development life cycle. The clarifications have an influence on the projects technical and nontechnical decisions.

Your project team should maintain a consolidated query register sheet to record the queries, assumptions, and the responses.  This query register sheet should be placed at location which is accessible to entire project team. Appoint a single point of contact (SPOC) responsible to ensure the query register is up to date and follows up with the right person to get a response for the open queries. This sheet should include functional as well as non-functional queries or to record the assumption for confirmation.  The query register sheet should be exchanged at regular intervals between the stakeholders. Formulate a format for the query register after discussion within your project team. Below is the sample general attributes of the query register sheet:

• Query description:
  Keep the language simple, non-ambiguous, one logical point at a time, if it helps the respondent, mention the original requirement context. 
• Screen dump or exhibit:
  Any additional information such as diagram, flowchart, or screen images of a scenario or representation. Information that helps the respondent to understand the query in a much better way. It helps reduce the query resolution cycle time and the quality of response.
• Severity and impact:
  To understand the risk of delayed response, classify the items in the query register sheet as either high, medium, or low as per the impact or severity of clarification on the requirement.
• Criticality or priority:
  It is possible for your team to generate many queries, considering the limited time on the hands of respondent and dependency of the clarification on the requirement. You could indicate the criticality or priority probably in terms of color code (Yellow: Low | Orange: Medium | Red: High) to help the respondent to focus on the high and medium level of queries first in that order. It allows them to allocate comparatively focus efforts to draft a response with more attention to the details.
• Date raised:
  It is a good practice to track when the query was raised to understand the age of the query and appropriate risk mitigation action to be decided by the project team.
• Status:
  It helps the project team to check on the status of the queries for follow-up and communication with stakeholders, the possible suggested status are Open| Close| Awaiting Inputs| Cancelled| On-Hold
• Assigned to:
  It helps to track the person responsible for the clarification, and ease in follow-up activities.
• Date required:
  Indicating a date by when the response or the clarification is required. The date required section helps communicate the projects expectations of timeline to manage the overall timeline which might be impacted due to the delayed responses.
• Resolution summary and response:
  To capture the responses, the resolution summary, and the clarifications of the queries and the assumptions to trace the requirements and their refinement through the query resolution. These responses help refine the requirement document, removing any ambiguity or misinterpretation.
• Date resolved:
  The resolution date when the queries or assumptions are clarified. It helps in identifying the slippage by comparing the date required and the date resolved.  
• Additional comments:
  Any additional comments or overall remarks about the query item in the register.  

 
Best practices
Consider the following when gathering requirements:

• Plan for extensive user involvement to determine correctness of requirements.
• Educate the stakeholders, especially users, about the need for their involvement.
• Expect and plan for the changes in requirements, which are inevitable.
• Ensure to gather both functional and non-functional requirements.
• Understand and use the vocabulary of the domain for better level of discussion with the business user. Include the business terms in the glossary section, which should become part of the requirements documentation.
• Do not think about the solution at the time of requirement gathering, it leads to less focus on requirement and attention to details.
• Make a practice to use flip charts, diagrams, exhibits, prototypes, visual tools, and so on as a starting point and to understand the requirement in better way.
• Focus on understanding business point of view and users tasks rather than user interfaces
• Conduct requirements gathering meetings with the users instead of ad hoc querying them during their regular work. 
• In case of remote requirement gathering, use technical aids to record user interactions. Make a point to ask the users’ permission before recording the discussion. It helps to trace the original discussion in case there is a change in requirement owners or the members in the project team.
• Ask open-ended questions, it helps to obtain more information from the user’s point of view.
• It is a good practice to document the rationale behind each requirement. It helps understand the primary objective of the requirement. It avoids any confusion to choose options which are favorable to this rationale at the time of selecting a solution among several alternatives.
• Try to probe and understand the users’ implicit expectations about the proposed system’s features, such as performance, usability, efficiency, and reliability. One of the approaches is to ask users what constitute as unacceptable performance, usability, or reliability.
• Do not hesitate to seek clarification for any doubt, unknown term, or ambiguous explanation. Explain to the user about the difficulty to understand the particular business terms been discussed, request for more elaboration. 
• You can think of questions that were already asked, rephrase them from a different perspective.
• Maintain proper documentation of all the client's communication for future reference. 

Application documentation

 
The application document is the final requirement document which is the output of requirement gathering and analysis. This document is generally known as the software requirement specification or system requirement specifications. This document should consist of a complete functional description as well as the behavior of system for all possible business use cases and its interaction with the users. In addition, the application document includes all non-functional requirements that enforce different types of design constrains. 

Best practice
When producing the application documentation, consider the following: 

• Keep sentences and paragraphs short. Use the active voice. 
• Use terms consistently and define them in a glossary or data dictionary. 
• To see if a requirement statement is sufficiently well defined, read it from the developer’s perspective to learn if it elaborates enough to design and implement.
• Do not merge multiple requirements as a single requirement point.
• It should have clarity about what is in scope and what is not.
• Every function and feature must be described in details with its appropriate non-functional constrains.
• Include use cases with appropriate use case diagram.
• Mention clearly the user acceptance criteria or the acceptance test scenarios for verifying the functions and feature and other non-functional constrains. This helps understand the benchmark expectation of the system for successful acceptance of the solution. 

Requirement prioritization

  
Requirement prioritization is a must when there are multiple requirements but not all of them cab be implemented at the same time due to certain constraints. The constraints can be time, budget, development dependencies, as well as business and technical risks. During project development, there could be new requirements for statutory compliance or change in policy implementation that takes priority on other matters. The constraints from the development project team can be too aggressive schedule to manage all of the requirements, skills availability in development team, and so on. When prioritizing the requirements, it is important to arrive at a mutually agreed terms of all parties that could mean reducing scope or breaking the application into several releases.  A proper requirement prioritization helps avoiding wastages ( time, effort, money, and other resources) and delivering the application features and functions in time for the business needs.

Both business users and developers should work together in prioritizing the requirements. In the process, derive from the requirements a list of the high level features that are expected from the proposed solution. Assign the importance levels of high, medium, or low to each features. The business users are to determine the level of priority for each feature. The developers are to identify the level of complexity of each feature. The complexity indicates the difficult level (in terms of efforts) to deliver a particular feature. The developers should also identify the level of risk for each feature in high, medium, and low based on the impact on the system had the feature is not delivered in the release under consideration.  

Best practice
Consider the following for the requirement prioritization:

• Identify the need for the prioritization of requirement.
• Prioritizing the requirements as early as possible to ensure the resources are invested for critical activities.
• It is essential for the user community and the development team to come to a common agreement on the prioritization.
• Obtain a user sign-off on the requirement prioritization sheet.

Parent topic: 2.0 Application development lifecycle