Guidelines

The purpose of this guideline is to elucidate the best practices to be followed when the requirements gather on a project are documented. This guideline does not have the objective of being prescriptive; it is more a source of guidance describing how to produce requirements to a high quality.

Many people often view functional requirements analysis (often requirements analysis generally as a process that does not add much value to a project (particularly clients). They feel they know exactly what the solution must do, and assume that they know what it should do exactly and are able to communicate this to solution developers. The reality is that this is simply not true, but because of this misconception, when requirements analysis is carried out not enough time is allotted to the task.

Functional requirements are the hardest of all forms of requirements to tie down as they are so intrinsically linked with humanistic needs. Therefore functional requirements take up most of a systems analyst’s time on a project. In the real world there is only a finite time allotted to requirement analysis, and often they are submitted before the analysts consider them to be a complete picture due to project or commercial reasons which are valid.

If an analyst has to submit their analysis work before they consider it to be complete, this fact must be communicated and the areas which lack completion highlighted and recognised as a risk. It should be noted however that an hour extra spent on driving a requirement down to fine detail can save a designer days or weeks, a developer weeks and project managers a lot of explaining to do.

Requirements defenition

When ascertaining and documenting Requirements they will be grouped into the following top level packages:
1.Functional Requirements
Functional requirements depict the functions that the client expects to be able to perform within the solution.
2.Non-Functional Requirements
Non-functional requirements can be broken down in to the following 2nd level packages:

1. Business requirements
   • These requirements describe needs of the customer which are not directly linked to any particular functions of the solution but describe a business objective which must be achieved as a result of the system being developed.
2. User Interface Requirements
   • User interface requirements described how the customer would the solution to interact with the users of the system.
3. Hardware Requirements
   • Hardware requirements describe the hardware which will be available to be utilised by the application in order to achieve the solution objectives. This type of requirements is very closely related to the performance requirements.
4. Software Requirements
   • Software Requirements describe the various software needs of the solution such as operating system,browsers to be used, protocols, third parts software etc ...
5. Performance Requirements
   • Performance requirements describe the expectations that the customer has in terms of how the solution will perform under specified conditions.
6. Security requirements
   • Security Requirements defines system access levels and data protection requirements. Desired security expectations should be described at both hardware (net topology, firewalls etc.) and software (checks,constraints, validations etc) levels.

Functional requirements

Functional requirements depict the operations that the client desires the solution to be able to perform. This is the most important type of requirements which a System Analyst can capture on any project as it answers the question “What does the solution have to do?” Non-functional requirement are mostly constraints which we have to work with in order to make the solution do, what the functional requirement state it must do.

The functional requirements mission

Often clients have a broad idea of what they want but are not very good at describing this to a level of detail which we can consider to be a functional requirement. Sometimes gaining functional requirements from a client is like obtaining blood from a stone (although it is much simpler in reality!), as they either lack time, detailed knowledge and understanding of what they want, or they are bad at communicating. Whatever the reason, it is up to the System Analyst to circumvent these issues and draw the blood from the stone.

Walk through high-level requirements

The most common situation which a System Analysts is in is where a client uses a high-level broad description of what they want a solution to do. An example of such a situation is where a client stipulates that they want a web shop where they can display and sell their products online. Often a client will believe that this is sufficient in order to get on a performed the development, when it is clearly not the case. Without thinking very much this requirement could be take us up very different paths, many of which are not what the client really wants, although they satisfy the basic requirement as stated by the client.

In order to establish the requirement, it is often useful describing the processes which are involved with the solution as a check that their requirements are understood by both the System Analyst and the client themselves.
Walking through the above example, the analyst could describe the process from a user of the web shop point of view. Soon questions will erupt either from the client or the analyst where it could be established that the client would like the user to be able to order the item online via a credit card system, and then record the orders to be used for when the user logs on next.
This would involve a user having to register their details when making purchases. This would also involve the data being stored securely as credit card information will be stored.
There was no mention of credit cards, registering etc… initially however these important requirements were flushed out through stepping through the high-level requirement.
When faced with such requirements which lack definitive clarity walking through the process with the client most often flushes out many other requirements (more detailed) which the client had either not mentioned or not thought off.

Don’t forget the administration bit

One common aspect which many clients (and Analysts) forget is that for every item of data held in the solution, the client will normally want to be able to modify/administer it. This area is often trivialised, without just cause, as often this area is more complex and takes longer to develop than the presentation of the data. Each time an Analyst sees data elements in the requirements, and does not see any means to administer it mentioned, alarm bells should be sounding loudly.

Ask Why?

The most important word when gathering functional requirements is the three lettered word “Why”. Often requirements are expressed without their being a “real” need or because the client has rushed to a solution without thinking of alternatives.

An example of its importance can be illustrated in the following example:
A user states that “a coffee pot must be made of stainless steel”. An analyst could ask “Why?” they need that particular material, and they may say “because a glass pot may break”. If the analyst then asked “Why should it break?” the user may answer “because the pot is often left on the heat oven even when empty”.
If the analyst asked why this happens they may be told “because the pot is shared by many people who just pass through, and the heater does not switch off when the pot is empty”. So as we can now ascertain the correct requirement is that the coffeepot heater should switch off when the pot is empty. However this is a million miles away from the initial requirement the customer stated.

A picture paints a thousand words

Most of us find it hard to visualise a proposed solution or a process without the use of a diagram or ten. Clients also suffer from the same problem. Therefore the analyst should utilise diagrams as and when necessary in order to clarify the requirement in their mind as well as check that the client is clear in their minds too!

Can it be done?

When a client request the solution to perform a certain function the analyst should always think: Can it be done? The analyst need not be a developer or designer to understand that what the client desires, just cannot be done, be it for technical or logical reasons.
If this is brought to the client’s attention in the requirement phase of a project, it is far easier to get a compromise from a customer, than if the customer is told half way through development that their requirement cannot be done.
Granted there will be some requirements which will be established to be impossible during development, but these can be minimised by an analyst thinking about whether it can be done or not. If possible an analyst should be thinking “how would I do it, if I had to and had the necessary skills and time?” If the analyst can answer this question, more often than not the requirement can be achieved.

 

Non-Functional requirements

The purpose of the following section is to provide a list of questions which a Systems Analyst can select a subset from, in order to be able to stipulate as detailed as possible non-functional requirements.
Functional requirements are largely project dependent in terms of their subject matter, whilst non-functional requirements are fairly consistent across projects regardless their subject matter although the details/values will differ from project to project.
The lists in this section do not purport to be exhaustive and nor do they purport to be a list of mandatory questions. They are more a guidance as to the type of questions that a System Analyst should be asking in order to establish the non-functional requirements of a project.

Business Requirements

A business requirement can simply be described as the business reason why the analyst is working on the project to produce the solution for the client.
Clients do not employ analysts, developers, designers and project manager’s to produce software solutions which do not have a business need, as the software development world is an expensive one to play in without no cause.
Establishing the business drivers behind a project can assist the analysts in helping the client define the solution they actually need, rather that what they think they need.
Analysts do no necessarily have the business expertise in the domain which the client practices in, and asking business associated questions both establishes the business drivers behind the project and the analyst can gain some insightful business domain knowledge which will assist the analysts in understanding the project better themselves.

Below and overleaf are some typical questions which the analyst should ask a client in order to ascertain the business requirements of a project:
• Why does the project exist?
• What is the business reason of the project?
• What are the key business drivers to determine the success of the project (i.e. increased productivity, reduction in costs, increase in sales etc…)?
• Is the solution backed more by technological decisions rather than business decisions? Is it a process driven change?
• Do they facilitate business change, which will inevitably happen?
• What is the expected life of the solution?
• When is the solution expected to have paid for itself?
• Is the purpose of the solution measurable in terms of ascertaining the success of the solution? If not how does the customer plan to evaluate the success of the solution?
• Has the user performed a GAP analysis in order to establish the requirements of the solution?
• Does the current business processes fit well with the technical processes part of the new solution?
• Is the new solution replacing an old one? If so why? Did the old one fail in its objectives? Has it been made obsolete?
• How does the project fits into wider business plans and programmes
• Who are the key stakeholders?
• Who from the customer will be providing most of the requirements, needs and feedback?
• Who are the proposed key users of the solution?
• Are any existing members of staff going to be replaced as a result of the solution being adopted (source of political tension…)?
• Will there be process changes at the same time as the adoption of the new solution?
• Are there any major business activities such as mergers, takeovers, floating etc… coinciding with the solution development/deployment?
• Are there any major business activities such as mergers, takeovers, floating etc… which will have an effect on timescales of delivery?
• If the user has existing data from the current systems, will this need to be migrated into the new solution? If so who will be responsible for this task?
• Will the client be first do market? Is that their aim?
• Who are their competitors?
• What differentiates the client from the competitors?

User Interface Requirements

The user interface is the human door to a solution. The average user does not want to see the nuts and bolts which securely hold the solution together, they want to work with the solution, and this is does normally via a graphical user interface (although not always graphical). Ascertaining the user interface requirements of a client for their solution is very important as that is how most people are going to judge the success or failure of the solution.

Below and overleaf are some typical questions which the analyst should ask a client in order to ascertain the user interface requirements of a project:
• Does the user require only a command line type interface?
• Does the user require both a command line type interface as well as a graphical interface?
• Does the user require a web-based user interface or an desktop application based user interface?
• Will we or the customer be developing the customer’s UI?
• Will the customer require prototypes? If so what prototype strategy will be employed (i.e. throw away, embryonic…)?
• If prototypes are to be produced what is their Scope (i.e. Subset of functions, all of them…)?
• If prototypes are to be produced who will be the target audience?
• If prototypes are to be produced will it be a signed off deliverable?
• Is the customer image conscious?
• Does the customer possess user interface guidelines, if not should we follow Compudava user interface standards or other user interface standard?
• What are the colour schemes which can be used within the solution’s user interface?
• Does that customer have any branding they wish to have employed in the solution? If so does the customer posses examples?
• Are we updating an existing produce where the branding will be constrained by the legacy application? Or will the user interface be based on a new vision?
• What kind of coverage of the disabilities act is expected? (i.e. AA, AAA rating….)
• What are the customer’s data input methods? (i.e. Mouse, keyboard, bar code scanner etc…)
• Are there any technical accessibility constraints? (i.e. no client side scripting, flash…)
• Which resolution must the solution support?
• Does the customer have any preferences relating to the existence of horizontal and vertical scrolling bars?
• Are there any particular data controls which the data prefers or dislikes?
• What type of user will use the application in terms of technical and subject matter knowledge? Who is the audience? What is the assumed level of understanding of the users?
• What is the percentage between pages for internal users and those for external users?
• What languages and currencies must be supported?
• What type of outputs other that on-screen is required (i.e. reporting, exporting etc…)?
• Must the application be compatible with different operating systems? This may affect the language used in order to create the user interface.

Hardware Requirements

All software solutions require hardware on which to run on, it cannot work without it. It makes sense therefore to find out exactly what the solution is planned to be running on.

These details often guide in a major way many of the design decisions that are made once the requirements and use cases are passed to the design team. In order to allow the designers to design the most suitable solution, as many details pertaining to the hardware requirements should be ascertained by the analyst.

Below and overleaf are some typical questions which the analyst should ask a client in order to ascertain the hardware requirements of a project:
• Either the client will have to specify the hardware on which the solution is going to be installed, or they ask us to specify the hardware which they require to meet performance objectives.
• Regardless who specifies the hardware, the following will have to be established:
a) Number of Servers
b) Number of processors
c) Processors
d) RAM
e) Type, number and size of hard drive(s)
f) Type of hard disk controller(s) (i.e. RAID, IDE, SCSI…)
g) L2 Cache
h) Number and type of network cards
• Bandwidth to be supported
a) Type of communication between Server and Client
b) Type of communication between Server and other servers in the solution (i.e. Database server and Web Server)
c) Type of communication between Server(s) and other customer systems the solution will interact with that already exist.
• What budget does the client have for purchasing hardware for the solution (if they divulge this information)?
• What is the typical upgrade cycle in terms of hardware for the client (i.e. All desktops every 2 years….)
• Where are the server(s) to be part of the solution or to be involved in the solution in any other way to reside? (i.e. Client site LAN, data centre, multiple client sites with WAN…)
• Does the client already have recovery plans for other servers which will apply to the servers used in the solution?
• Will the client require redundancy to achieve promised SLAs or guaranteed up-time?
• Will we utilise servers already purchased by the client for the solution?
• Has the customer planned to have a test environment prepared for UAT?

Software Requirements

The solutions we develop often interact with one or more software elements on the client’s environment. Often these interactions constrain the way in which we can develop the solution or at least will guide the designers in design the best solution according to the scope of interaction with other software.
Below are some typical questions which the analyst should ask a client in order to ascertain the software requirements of a project:
• What software should the solution be compatible with?
a) Browser
b) Operating Systems
c) Third part software
• How portable should the solution be? (i.e. we develop for MySQL now but know that in future releases it will have to be ported to SQL Server)
a) Operating System
b) Database
c) Application Server
d) Programming language
• When developing the solution whose coding standard need to be followed?
a) Compudava coding standards
b) Customer coding standards
c) Other coding standards
• Who will support the solution post deployment?
a) Compudava will provide support
b) Customer will support the solution themselves
• Has the customer expressed any of the Third Party software which must be used by the solution?
a) Operating System
b) Database
c) Application Server
d) Programming language
• Has the customer assigned any of their budget towards the purchase of licences, which may constrain the software that can be utilised?

Performance Requirements

How many times have we heard that the solution must work as fast as it can? Is that a real requirement? It sounds like a vague requirement which is not really measurable. In order to prevent designers and developers dealing with such vague requirements, it is up to the analysts to ascertain what level of performance the client expects and what constraints must the designers and developers deal with.

Below and overleaf are some typical questions which the analyst should ask a client in order to ascertain the performance requirements of a project:
• How many named users is the customer expected to use the system?
• What will be the maximum number of concurrent users of the system?
• What will be the maximum number of concurrent users in peak times? What is the duration of these peaks, and how often can they appear?
• Establish a set of key scenarios which will be the typical usage of the system. The following details for each scenario should be ascertained:
a) What are the components of the scenario? (i.e. steps)
b) Number of users (as a percentage) which will perform each scenario daily.
c) The frequency each scenario is going to be employed per day
d) How much sleep time (i.e. user’s thinking time) is appropriate?
e) What is the acceptable and expected maximum response times for each scenario for each type of connection which is relevant (i.e. LAN, 512kb link, 28kb link…).
f) What is the acceptable and expected maximum client perception time for each scenario for each type of connection which is relevant (i.e. LAN, 512kb link, 28kb link…).
• Are there any functions which the solution will perform which can be identified early as being business critical and/or resource hungry? If so specify these as these will form the starting point for performance testing and tuning.
• What is the current and expected volume of data which will form part of the solution by object type?
• What is the expected growth per object as a percentage per month/year?
• What is the expected average size and number of external objects (other than code or data)? (i.e. Images, documents, files…)
• What is the expected availability of the solution? If the client states 24x7 ensure that the client really means 24 hours per day, 7 days per week, 52 weeks per year, 12 months per year etc….
• What level (i.e. errors, security, object creation, modification and deletion…)of auditing is required?
• Where will solution data be stored?
a) Flat/XML file
b) Relational database
c) XML database
d) Other

Security Requirements

When a client mentions the words username and password when specifying requirements for the solution, the analyst should immediately think about security in a broader way. The questions below will assist the user in ascertaining detailed security requirements.

• What is the type of solution that is being created?
a) Intranet Web Application.
b) Intranet Desktop Application.
c) Internet application which provides public information.
d) Internet application which manipulate sensitive data (financial transactions, secret documents etc).
e) Other?
• What methods of authentication will be used?
a) Web Based authentication
b) HTTP Authentication:
a. Basic
b. NTLM
c. Digest
a) Other?
• Should system forbid simple passwords (i.e. master, john23, administrator) and allow only strong ones (i.e. @&#J83^zx#0(-+, WeN6%2@!]dEp>)?
• Should brute-force attacks be avoided and if so how? i.e. After 5 incorrect login attempts user was locked for 15 minutes.
• What events are to be logged?
a) Any exceptions are logged.
b) Any possible attacks are logged (Incorrect login attempts, authorization bypass attempts, data validation bypass attempts and other).
c) All user activities
• Should the user have the possibility to recover lost passwords themselves (System provides password reminder mechanism) or will it only be able to be reset by an administrator (sent to user by email, SMS etc…)
• How are sessions to be maintained if they are to be implemented?
a) Cookies
b) Session Tokens
c) Other?
• What are the session options?
a) Specify in seconds/minutes/hours timeout period
b) Should system allow multiplicity (i.e. Can the same login in the same time from different locations?)
c) What algorithm of session token generation should application use?
• How should the application handle bad data?
• Should there be Client side validation? i.e. JS Validation is made in browser to avoid additional flow of data.
• How sensitive is the data which the solution will store and access?
• Is there any credit card/other financial information which the solution uses and stores?
• Are there any legal requirements pertaining to the protection of any data which is being stored and accessed by the solution?
• What level of security is the client expecting?
• How important is security in comparison to performance?

Requirements Change Control

Changes to requirements can occur at any time throughout the life cycle of a project. The two most frequent times for these changes are as follows:

• Before the requirements are signed off by the client
• After sign off as a change request

If the requirement is changed before they are signed off, there is no issue relating to change control of the requirements, as they are not part of a baseline.Once the client has signed off the requirements, any changes are a change to a baseline and therefore must be tracked.

 

FR - Functional Requirements

This is an early draft.

Functional requirements for IofC Drupal project. Version 2.2
		Notes	Open issues (19)	Phase	Priority	Difficulty	Version
FR01	Multiple Domains/Sites	This package relates to the functionality required for providing multiple websites within one integrated system.		1			1
FR01_01	The solution must deliver an integrated system for running many domains/websites	initially 20-25, but growing.		1	High	High	1
FR01_02	Each domain/website must be able to define a look for its user interface using site specific theme using theme, menu and administration.			1	High	High	1
	Each domain/website must be able to build its own content.
FR01_03	Nodes, images and users/contact records must be shareable across all domains.			1	High	High	1
FR01_04	Solution must use single Drupal's codebase for all websites	Having one codebase we can simplify process of installation of security patches and upgrades of Drupal core.	There are a lot of tricks how to achieve that. WE should choose one which suites the best for our needs.	1	High	High	1
FR01_05	A User must be able to login from any site provided by solution .	Users are shared across all sites, so that any authenticated user has access to the ‘private’ part of any website, and is able to move seamlessly between these ‘private’ websites without being required to log in again.	How to share user's accounts ? Think about global Directory using OpenLDAP. www.openldap.org Dupal modules: ldapauth, ldapgroups, ldapdata. Seems to be promising for that.	1	High	High	1
FR01_06	Each website (an international one, and 20-50 national and programme-oriented ones) needs to have both: A ‘public’ part (for anonymous users) and A ‘private’, community part (for authenticated users)		Notions “public” and “private” site-part are misleading here. It sounds like 2 separate places. Do you agree ? Each Drupal basic building block (node) must have access attribute, that will differentiate a node like public ( for anonymous users) or private ( for authenticated users)
FR02	Groups	This package relates to the group system to be implemented.		1			1
FR02_01	Solution must provide dynamic “Group creation” functionality	The process of creating a Group must be easy and intuitive and minimise the need for intervention by sitewide administrators. 4 group roles should be created automatically for a group when that group is created: * Member – defines who is part of the Group * Administrator – can administer all parts of the Group's membership except editing of contact records. * Webmasters – administers pages and content for the Group, including for a public website belonging to the Group. * Data Controller – responsible for those contact records assigned to the Group's data controllership (if any).	One group may have a website, but another may not. If a group does not requires a dedicated website, then why does it require a Group-webmaster role in place ?	1	High	Unknown	1
FR02_02	Solution must provide dynamic “Subgroup creation” functionality	A group must be able to contain another group, so that the members of the subgroup are also members of the containing group.		1	High	Unknown	1
FR02_03	Group creation operations must be tied to a role.	Any Advanced User may create a Group.		1	High	Unknown	1
FR02_04	Group administrator must be able to define additional group specific roles	Any group member may have as many roles as required.		1	High	Unknown	1
FR02_05	Group must be able to create ant type of Content	A site may have many groups associated with it -- when a user creates a new site at least one group must be specified -- that group's content (team homepage etc.) will automatically be linked to the new site.		1	High	Unknown	1
FR02_06	Each group must have its own calendar	Events will be shown in group-calendar. Group administrator can hide events from their group calendar.		1	High	Unknown	1
FR02_07	Access to some content on each private website must be able to be limited to a group. Groups need to be able to have their own Group pages/menus, etc within any domain/site.
FR02	Internationalisation	This package specifies the multilingual functionality required.		1			1
	Each website must be deliverable in two or more languages.	where needed		1	High	Unknown	1
	Solution must provide a possibility to install additional languages.	English will be default language for the system. Other languages installed initially will be: French, German, Swedish, Norwegian, Finnish, Dutch, Spanish, Portuguese, Russian, Chinese, Japanese.		1	High	Unknown	1
	There must be provision for RTL languages.	Drupal core provides RTL		1	Low	Unknown	1
	On a multilingual website, the visitor must be able to choose from available languages. Chosen language must be used for user interface.	The user interface must be in the chosen language, where translated strings are available. Strings must be multilingual		1	High	Unknown	1
				1	High	Unknown	1
	Content/nodes must allow a translation workflow.			1	Medium	Unknown	1
	The translation workflow should have an automated notification systems for translators.			1	Low	Unknown	1
FR03	Theming	This package describes issues related to the look and feel of the website.		1			1
FR030_01	Themes for national and programme websites must be easily cloned and adapted from default template.	The default theme must be based on the current template at www.iofc.org		1	Low	Low	1
FR030_02	Solution must provide UI template support	Visually unrelated themes must also be available for some websites.		1	High	Low	1
FR04	Content	This package details the main types of content to be used.		1			1
FR04_01	Support for following content types must be provided: Page, Article,(Story), Event, Blog, Book, Forum, Project and Project issues, Images, Feedback, Comments	A node must be editable only by its creator and by users of the group which 'owns' it.		1	High	High	1
FR04_02	Each content type may have its own required fields, in addition to the default set.		What is the purpose of that “required field” ?	1	Unknown	Unknown	1
FR04_03	Each content type must be configurable to allow revisions, comparison of revisions, and reversion.( Except Comments)			1	Low	Low	1
FR04_04	Nodes must be shareable across domains and groups unless specified below.	Thus a node published on Site X would generate the following possible options: * It could be published by Webmaster X only on Private Site X and/or on Public Site X * It could be shared with the Network (all sites) but not actually published anywhere else by default * Webmaster Y could then decide to publish this node only on Private Site Y and/or on Public Site Y * Only the creator of the node (Webmaster X in this example) is allowed to edit/delete the node * Webmaster X needs to be able to publish the node only to Group Z (a group exclusive to Site X), in which case it would be visible only to members of Group Z on Private Site X and not anywhere else on Site X or in the Network. Webmasters of Sites Y and Z obviously need a method to view all nodes which have been ‘shared’ by other Sites, and decide whether to publish them to their site. The only amendment to the general rules above might be that a node published in Site X (but not restricted to a Group) might automatically also be published to Private Site A (the private/community section of the parent/hub/international site).		1	High	Very high	1
FR04_05	Vocabulary of types must be used for content classification.			1	High	Low	1
FR05	Page			1			1
FR05_01	It must be possible to create Pages.	Pages may only be added and edited by Webmasters		1	Low	Low	1
FR06	Article (Story)			1