Business user requirements for it development
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Business user requirements for it development

on

  • 1,941 views

A business requirements document will be used to write the systems specification document (blue print for building software / hardware solutions)...

A business requirements document will be used to write the systems specification document (blue print for building software / hardware solutions)

Businesses that do not take time to complete this document face uncertainty in the User Acceptance Testing (UAT) phase, as they have not built the requirements into design.

Statistics

Views

Total Views
1,941
Views on SlideShare
1,927
Embed Views
14

Actions

Likes
0
Downloads
33
Comments
0

2 Embeds 14

http://www.simonmisiewicz.co.uk 11
http://www.linkedin.com 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Business user requirements for it development Presentation Transcript

  • 1. Creating a Business requirements document for IT / technology development Simon Misiewicz
  • 2. Creating a Business requirements document A business requirements document will be used to write the systems specification document (blue print for building software / hardware solutions) Businesses that do not take time to complete this document face uncertainty in the User Acceptance Testing (UAT) phase, as they have not built the requirements into design. Simon Misiewicz
  • 3. Considerations for the Business requirements document Business Process Requirements User Requirements System Performance Requirements Security requirements Simon Misiewicz
  • 4. Business Process Requirements Understand the business processes before designing any new system. What is the “as is” process and what do you want the “to be” process after the implemented system? What are the current issues and can they be addressed with technology? Simon Misiewicz
  • 5. Business Process Requirements
    • Any proposed systems to be implemented should consider the end user in regards to:
    • What business processes must be catered for?
    • What authorisation/approval processes must be catered for (e.g. booking approval, contract sign off, payment authorisation)
    • Does the solution need to manage work flow?
    • Are there any strategies that the solution must deliver to? (Marketing strategies, target populations, resource strategies)
    • Are there any external strategies that must be delivered to? (e.g. e-Government etc)
    Simon Misiewicz
  • 6. Business User Specification Consider the needs and desires of the end users to ensure that they psychologically buy into the solution. Listen to their needs and make sure they feel involved in the process or face resistance Simon Misiewicz
  • 7. Business User Specification
    • What information needs to be displayed?
    • Does information need to be displayed in a certain order?
    • Does information need to be displayed in different languages and if so which ones?
    • Do you need to be able to restrict what information is displayed and by what controls?
    Any proposed systems to be implemented should consider the end user in regards to: Simon Misiewicz
  • 8. Business User Specification
    • Do screen layouts need to be definable or customised?
    • Do different users need to be able to have different views?
    • How should dates & times be displayed? (e.g. 4 digit year, UK or US format etc)
    • What controls are needed: Searches, Filters, sorts etc?
    • What methods of navigation should be used? (e.g. Scroll bars, date entry, navigation buttons etc)
    Any proposed systems to be implemented should consider the end user in regards to: Simon Misiewicz
  • 9. Business User Specification
    • Does information need to be displayed in a consistent way?
    • Are there any branding standards that need to be adhered to?
    Any proposed systems to be implemented should consider the end user in regards to: Simon Misiewicz
  • 10. Data / information requirements How will data be acquired, processed and reported? Considering these needs will ensure that information / reports are available post implementation Systems should be designed to communicate with one another to avoid manual interfaces / duplication of effort Simon Misiewicz
  • 11. Data / information requirements
    • Are there any database engines that must be used? (E.g. SQL, Paradox etc)
    • At what level must record locking occur?
    • What directory standards apply? (E.g. Active Directory, LDAP, NDS, NTDS etc.)
    • Is efficiency of data storage important?
    • Are there any restrictions on storage space available?
    • Will the data be stored on the same server as the application or separately?
    Simon Misiewicz
  • 12.
    • Will any specific data storage technologies be used? (e.g. SAN)
    • Are there any archiving requirements?
    • Do you need to archive by particular parameters?
    • How long information must be retained for?
    • Are there any data optimisation requirements? (e.g. Data compression etc)
    • Are there any data retrieval performance measures that must be met?
    • Are there any data migration requirements?
    Data / information requirements Simon Misiewicz
  • 13.
    • Will there need to be an ability to import data from existing systems, spreadsheets etc?
    • Are any data migration tools required?
    • Are there any file formats that interfaces must adhere to?
    • Are there any checks/balances that must be done to ensure data is passed correctly through interfaces?
    Data / information requirements Simon Misiewicz
  • 14. Performance requirements Understanding how fast and reliable the system needs to be can safe problems in the future. Simon Misiewicz
  • 15. Performance requirements
    • What services are to be provided?
    • What are the days/hours during which the services need to be provided?
    • What are the service level expectations? (e.g. 95% first time fix)
    • How will service quality be monitored and measured?
    • Are there any specific requirements about how the services are provided? (e.g. Single point of contact, document escalation path etc)
    • Will remote access be required?
    • Does there need to be a permanent on-site presence?
    Simon Misiewicz
  • 16. Performance requirements
    • Who will install fixes?
    • When will fixes be provided?
    • How will support calls be prioritised?
    • Who sets the priority of support calls?
    • Is minimum support employee to customer ratio required?
    • How critical is the solution?
    • Do service failure penalty clauses or service availability incentives need to be provided?
    • Who will deal with the supplier?
    • Who will be responsible for contract renewals?
    Simon Misiewicz
  • 17. Performance requirements
    • What service/call reporting is required?
    • Do we need an input into future developments of the product?
    • Should upgrades/patches be chargeable?
    • Who retains ownership of replaced equipment?
    • Is an Escrow agreement required?
    • Under what conditions should we be able to demand an on-site presence and should this be chargeable?
    • Who should pay for what?
    • What should be the period of the support?
    Simon Misiewicz
  • 18. Performance requirements
    • Is a commitment not to withdraw support for the solution for a set number of years required?
    • What should happen if a problem cannot be resolved?
    • What should happen in the event of dispute as to the cause of a problem?
    • Do we need the supplier to operate a user forum?
    Simon Misiewicz
  • 19. Security Requirements Consider how the data and hardware will be protected from malicious attacks or accidental loss to safeguard valuable assets Simon Misiewicz
  • 20. Security requirements
    • Should there be any limit on the maximum number of users?
    • What facilities for managing users are required? (E.g. password management, Set up user accounts, Set up access rights etc).
    • What system admin controls are required? (e.g. revoke, suspend or modify user access rights)
    • Does the solution need to provide any password functionality? (e.g. Ability for users to change their own passwords; Min and max retention periods; History of used passwords; Expiration dates)
    • Should there be any restriction on what passwords and user IDs can be used?
    Simon Misiewicz
  • 21. Security requirements
    • What structure must passwords and user IDs be in? (e.g. Min/Max length, alphanumeric etc.)
    • Does the solution have to have any automated security functions? (e.g. Auto suspend user after a number of invalid logon attempts; Inactivity time out, Force password change)
    • What controls need to be in place to ensure security isn’t compromised? (e.g. password encryption, access rights limited for user management etc)
    • What different levels of access are required? (e.g. access to individual functions, access to particular types of data, read/write/amend etc)
    Simon Misiewicz
  • 22. Security requirements
    • Is there a need to manage groups of users together?
    • What security logs need to be maintained and what information needs to be in them?
    • Do any devices need to be used to gain access? (e.g. swipe card, biometrics etc)
    Simon Misiewicz
  • 23. Testing requirements Understanding the business processes and user requirements is vital in writing the tests to be performed on the system. Performing tests provide assurance that the system meets all the requirements for it to be approved and implemented. Simon Misiewicz
  • 24. Testing requirements
    • Questionnaires
    • How will you develop questionnaires to ensure that their needs are met?
    • How will questionnaires be communicated to users: in person, meeting, work group, email, intranet etc?
    • How will the results be reported, grouped and analysed?
    Simon Misiewicz
  • 25. Testing requirements
    • Functionality
    • Will a test environment be developed so that users have a free reign of the system?
    • How will issues be reported, tracked and resolved?
    • Who will test the system, are they experts, novices or a good range of people?
    • How will the back end functionality be tested?
    Simon Misiewicz
  • 26. Testing requirements
    • Data flows / business process
    • What types, volumes of data will be pushed through the test system?
    • Who will run the test data through the system, is there sufficient sample size of data and users to be confident that the system has been adequately tested?
    • What error trapping devices / modules are in place to ensure that issues are immediately detected?
    • How will data be checked to ensure that the actual output results are the same as the expected results?
    Simon Misiewicz
  • 27.
      • For solutions
      • Contact Simon Misiewicz through
      • Web: www.simonmisiewicz.co.uk
      • Email: [email_address] or
    Simon Misiewicz