Technical Requirements

Technical requirements include detailed descriptions of the technical architecture framework, database definitions, business rule engines, program logic, development objects, application interfaces, network architecture, security components, and many other of the technical specifications of a solution. These technical requirements (also referred to as specifications) specify how the solution should be built and integrated into existing systems in the organization. The technical requirements are developed based on the functional and non-functional requirements agreed upon by the business stakeholders and sponsor. They include hardware descriptions, database designs, programming standards, and guidelines. They may include specific product names of software development tools that will be used. In addition, the technical requirements will include a description of how interfaces to outside systems will be accomplished. These descriptions include data sent to, or received from, other applications and any required conversion algorithms. BAs rarely write technical requirements (unless a BA is also playing the role of IT architect or systems analyst), but may be asked to review them. This review process allows the BA to confirm that the technical plans support the true business needs (via the functional requirements).

Stepping through the categories of requirements and their relationship to each other shows the importance of identifying complete requirements from the beginning. When business requirements are used as the basis for solution design discussions (as they should be), they must be complete. A missed business requirement will result in several missed functional requirements and may drive the technical architecture design in a way that prevents the business need from being easily added later.

Core requirements components

After using and understanding many business analysis techniques, a few common core components emerge. Each analysis technique looks at a requirement or set of requirements from a unique perspective. Looking at a requirement from different perspectives is like picking up an object (e.g., a cell phone or a can of soda) and examining it from different sides, at different angles and in different lights. If the object has moving parts, you move them to watch how the object changes. Carefully examining the object gives you information about its construction and its uses. Looking at a requirement from all “sides” helps the BA more clearly understand it. Breaking a requirement into its core components opens the moving parts and lets you examine it from the inside out.

The core requirements components are data, process, business rules, and external agents. The techniques and approaches used to analyze a project must encompass these four components or you will miss an important part of your analysis. Figure 6.1 shows an example of these components.

Figure 6.1: Core Requirements Components

Breaking requirements into these core components is a strong analysis technique that should be constantly practiced by the business analysis professional. This is a fundamental analytical skill that should become automatic over time. Experienced analysts begin to identify these components as soon as a business person begins describing his or her business.