logo for information-management-architect.com
leftimage for information-management-architect.com

System Analysis and Design
Non Functional Requirements

Need to complete system analysis and design for an information management requirements specification and want practical timesaving suggestions?

Non functional requirements are system requirements needed to satisfySystem Analysis and Design functional business requirements.
 
How do we determine system requirements?

These are mostly technical in nature and need to be defined by the architecture and design team and the operations support team.

This sounds technical, why are they in a requirements document?

Some project development methodologies have two requirement documents:
  • Business requirements, which identify all functional requirements; and
  • System requirements, which identify all system related, or non functional requirements.
Information management projects are “data centric” and a lot of requirements are really system related, hence, they are included in the information management requirement specification.

The following non functional requirements should be considered when completing system analysis and design and non functional requirements analysis.

System analysis and design constraints

Examine the following topics and document any requirements that might impact architecture and design:
  • Legal and regulatory policies;
  • Existing systems limitations;
  • Hardware limitations;
  • Software limitations;
  • Communications constraints;
  • Architecture and design standards (should reference all standards and best practices);
  • Production support standards;
  • Data modeling standards; and
  • Operational environment standards.
System analysis and design performance requirements

Consider things such as:
  • Are there requirements specifying when needed functions are needed, e.g. ad hoc reporting?
  • Are there requirements for synchronization of databases?
  • Are there requirements governing the replication of data/functions across distributed platforms?
  • Are there specific constraints on acceptable response time (e.g. within a certain number of seconds for a specific percentage of queries)?
  • Are there response time requirements for specific queries or classes of queries?
System analysis and design quality and production support requirements

Consider the following:
  • Ability to audit, e.g. what type of data access is required to information maintained for audit purposes?
  • Reliability, e.g. how long should the system function without downtime?
  • Availability, e.g. specify the amount of time, during normal use periods, that the system must be available;
  • Data currency, e.g. are there constraints governing the maximum allowable latency for data? (Latency refers to the amount of time that has passed since the data was deemed current);
  • Flexibility, e.g. define requirements related to the degree to which the system can be changed to include new business functions and future technologies;
  • Accuracy, e.g. are there requirements governing the quality of specific data attribute values?
  • Consistency, e.g. are there specific constraints on user interface screens?
  • Maintainability, e.g. are user managed tables or parameters allowed, helpful or prohibited?
  • Scalability, e.g. will the solution require scalability across hardware and software?
  • Monitoring, consider requirements for monitoring:
    • Performance, e.g. what type of data access is required to information maintained for system monitoring purposes? What is the anticipated frequency of such monitoring?
    • Command and control, e.g. will there be a need to control the system remotely?
    • Failure management, e.g. should failures be detected both automatically and manually? How will failures be reported?
    • Logging, e.g. will data logs be required? What data will be captured and logged?
    • Error handling, e.g. is there specific data that must be captured in order to determine the problem source?
Training requirements

Identify training needed by users, to use the system, and production support teams, to operate and maintain the system.


Service Level Requirements
Service Level Agreement

Need to evolve service level requirements for an information management requirements specification and want practical timesaving suggestions?

Service level agreement is a term often used to define agreements, or Service Level Requirements “contracts”, between the IT department and users. These agreements normally state non functional requirements expectations about the availability of a system or service.

Suppose you are sending something by courier to another country. You usually get several shipping options depending upon how fast you need the parcel delivered.  Each option guarantees delivery by a specified time. 

Think of the restaurant that promises you a free meal if it is not delivered within a specified number of minutes. These are types of service level agreements.

Now think of an information management project!

Users may want the system from 8:00 AM to 6:00 PM weekdays and this becomes part of a service level agreement between the IT department and the user. This requirement might also need a series of other internal  “agreements” among the IT department. These may be formally documented or they may be defined in normal operating procedures.

It is important to confirm expectations as part of the requirements specification. If the IT department cannot meet the requirements due to resource or other constraints, then:
  • The requirement may need to be changed; or
  • The project may require additional funding to overcome the resource issues.
The following lists some items that should be considered for non functional requirements for service level agreements.

Source systems

Information management projects usually extract data from source systems. Consider…
  • What is the timing for each interface?
  • When is it expected to be available?
  • Who needs to be contacted if it is not available?
  • Who needs to be contacted if there is a problem with the data?
  • What are the expectations for fixing problems e.g. how long should corrective action take?
  • What agreement is needed for change requests, i.e. does the source system have production support staff to make changes or is a new project required?
System analysis and design for data quality

Data quality is a key concern for information management projects. Data quality requirements will normally specify what issues need to be reported. Consider…
  • What is the agreed resolution time, e.g. if issues are reported back to the source system owner, is a correction expected the next day?
  • What is the agreed time frame if a data steward is expected to fix errors?
  • Are there escalation procedures in case the issues are not resolved?
System analysis and design for back up and restore

Production database back up is usually scheduled per requirements and specify timing expectations for restoring production data. Consider the following requirements for development:
  • Is the development/test environment backed-up on a scheduled basis?
  • Is this a normal occurrence or does the team need to be notified when each back up will occur?
  • Can back-ups be scheduled to minimize impact on the development team?
  • What are timing expectations for restoring development test data?
Operational performance

Non-functional requirements specify performance-monitoring requirements. Consider…
  • What is the expected response time for issue resolution?
  • What is the escalation process if problems are not satisfied in a timely manner?
System maintenance

Consider establishing a “maintenance window” which can be used by the operations support team to perform routine maintenance such as installing operating system “patches”.

Help desk

Expectations for help desk support must be clearly stated so there are no misunderstandings—User’s need to know what level of support they can expect.

System availability

Service level requirements should specify the expected availability for all users in all time zones e.g. the system shall be available from 6:00 AM EST to 9:00 PM EST, Monday thru Friday, including holidays.

System Analysis and Design Summary…


Information management projects are “data centric”. Most of the requirements are non functional, and provide direction to the architecture and design team. It is critical that system analysis and design identify these non functional requirements requirements early in the project so that potential impact on project schedule/cost can be evaluated before requirement specifications approval.


footer for Information management page