The critical success factor for all these initiatives is the clear and precise definition of the functional requirements, defining the behavior of the system, and the nonfunctional requirements, describing how the software will do it and what it will not do.
The business users define the functional requirements substantially well but are challenged when detailing nonfunctional requirements. Asking business the right questions can achieve a better business-IT alignment.
Nonfunctional Requirements – Criticality and Lifecycle
In any software development effort, gathering requirements is the first step. Functional requirements describe the behaviors (functions or services) of the system that support user goals, tasks or activities, and nonfunctional requirements include constraints and qualities. Like functional requirements are tracked to closure during the various phases of the software development lifecycle, it is imperative to elicit, document and track NFRs to closure for the success of any software development project.
An NFR lifecycle usually proceeds as follows:
Identify NFRs applicable to an application situation:
- Identify the key/critical NFRs for the given engagement.
- Understand the significance of the critical NFRs; assess the impact if a given requirement is not met.
Define what is required by preparing a questionnaire for NFR stakeholders:
- Categorize NFRs into “should have,” “could have” and “nice to have.”
- Frame questions for qualitiative and quantitative NFRs.
- Validate the practicality of the NFRs.
Decide on potentially conflicting NFRs based on constraints:
- Establish a cost-benefit analysis of building a system complying to NFRs versus foregoing few aspects of NFRs.
Track NFRs captured from requirement to testing:
- Validate architecture, design and coding practices at various software development lifecycle phases.
- Create adequate test plans to validate that the end solution passes all NFRs stated/agreed upon.
Close/Execute test cases:
- Collect and document metrics to confirm compliance to NFRs.
Data Integration Initiatives and NFRs
In a typical data integration initiative, it is not uncommon that functional requirements may not be completely defined early in the project lifecycle; they get clarified as the project progresses. The clarity on nonfunctional aspects is much lower. NFRs are stated informally during the requirements gathering, are often contradictory, difficult to enforce during software development and hard to validate when the software system is ready for delivery.
Nonfunctional requirements seem less clear because:
- There’s a lack of understanding about what to include as nonfunctional requirements;
- No one is sure what should be specified, this results in exclusion or specification of unrealistic nonfunctional requirements; and
- People assume it is implicit.
NFRs Critical to a Data Integration Initiative
Nonfunctional requirements are as critical as functional requirements to the success of a data integration initiative. It is imperative that the right set of questions are asked during the requirements phase and that each of the nonfunctional requirements is tracked during the complete lifecycle of the project.
Performance
Performance is about the resources used to service a request and how quickly an operation can be complete, e.g., response time, number of events processed per second. In the context of a batch application, it may be insignificant, as things are not usually measured on a per second basis, but it is still important as SLAs to support downstream systems or applications. The key questions that could be used to help document performance requirements are:
What is the batch window available for completion of complete the batch cycle? Knowing the batch window can help the project team validate if the SLA can be met with the given input volume, process complexity and resources.
What is the batch window available for completion of individual jobs? There are scenarios where the in-process data is consumed by some of the downstream systems. Availability of this information can help define the batch dependency and design the batch more efficiently.
What is the frequency of the batch? The frequency may be different for different jobs. Not all days of the week will have the same incoming volume. The hardware on which the batch cycle runs could have varying loads based on the day of the week. A clear understanding of the frequency will help in tuning the batch based on incoming volume and expected resource availability.
What are the data availability SLAs provided by the source systems of the batch load? Detailed information of the availability service level agreements can help validate if the batch cycle can meet the required SLAs or not.
What is the expected load (peak, off-peak, average)? This key information needs to be obtained for all source systems, and the details gathered should include when data volume is expected to be high or low.
Are there any constraints imposed by the source system? The typical types of constraints are related to a time window when data can be pulled (or not), adding any additional filters while querying the data from a source system (because this may over load the source system).
What is the hardware and software configuration of the environment where the batch cycle needs to run? This is a very critical input for the design process, because this information can be used in suitably leveraging the capabilities of the environment. Examples could be in leveraging features of a version of software and leveraging hardware by multi-threading
Are the resources available exclusive or shared? If shared, what percent is available? If the deployment is in a shared environment, the availability of resources can be a useful input to determine if the batch SLAs can be met.
Be the first to comment on this post using the section below.