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 satisfy
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 
“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.
|
