software development
Tools for Requirements Gathering SessionsFor more helpful tips go to requirements.seilevel.com/blogTechniques to Trigger ThoughtsUse various tools as a starting point in requirements gathering sessions as opposed to starting from a blank slate.List of Questions – Prepare a list of questions ahead of time to use as a general guide for the session.Use Cases – Use cases describe the system from the point of view of the user using the system. They provide aneasy format for all people to quickly grasp the system’s functionality. Draft a use case to work from.Existing System – When working with an existing system, use it to trigger ideas quickly. Have the user walk throughhow they do the task now in the system. Talk about what users do and do not like about the system. Look at screenshots if you do not have the application handy.Whiteboard – Because visualizing the system or UI improves comprehension for many people, always use awhiteboard to sketch out ideas. Capture use cases, sketch out user interfaces or draw process flows on the whiteboard.Screen Mockups – For applications with user interfaces, start with mockups of the UI. Wire frames are simple blackand white boxes and text, specifically not focused on look and feel. Use paper, PowerPoint, or a whiteboard to draw theUIs.Questions to Ask in Requirements Gathering Sessions? What is the business objective behind the functionality requested?? What basic functionality do you need for this part of the system?? What is the underlying goal of the requirement?? Is this particular design critical to the business goal, or would any design be equally effective?? How does it work today?? What specific steps do you go through to complete a task in the system?? What do you not like about the system today?? If X does not happen, then what should happen?? What do you want to have happen in the future?? What known constraints are there from other systems or users?? What are the non-functional requirements that apply for each of the users, operating environments, and interfacingsystems?? Keep drilling deeper with variations of “why?”Questions to Ask When Developing Use CasesDescription? What is the actor’s goal?? What are the high level actions the actor will need totake to reach that goal?Assumptions? What assumptions are we making when analyzing thisuse case?Frequency of Use? How many times per minute, hour, or day will this usecase be executed?Actor? Who uses the system (what is their job)?? What other systems will interact with this system?? Who or what provides information to the system?? Who or what receives information from the system?Trigger? What event causes this use case to happen?? What actor initiates this use case?Preconditions? What conditions must be true before this use case canbegin?? What state is the system in before this use case canbegin?Success End Conditions? What conditions must be true when the use caseends?? What state will the system be in at the end of the usecase?Main Steps? How does the actor interact with the system?? What does the system do at this step (present options,display data, execute a process)?? What does the system do next?? What does the actor do next?? Is there part of this use case that is another use casecalled by multiple other use cases?Alternative Courses? What possible error conditions exist at each step ofthe main scenario?? If X doesn’t happen, what should happen?? What are the interrupts that can happen at any time?? What is the “non-happy” path?? What other possible actions can the user take at eachstep?? If the user cancels out at any step, what shouldhappen? Non-Functional Requirement Types and ExamplesFor more helpful tips go to requirements.seilevel.com/blogAvailability – Desired “up time” during which thesystem and data are available for use. [The systemshall be unavailable between the hours of 3AM and5AM inclusive every working day for maintenance.]Communications Interfaces – Any communicationfunctions the product uses are documented in thissection (example – web browsers). [The system usesHTTP protocol to communicate with the servers. Usersuse HTTPS (secure site) to login to the system.]Design and Implementation Constraints – Issuesthat will restrict the options available to thedevelopment team, including the reason for theconstraint (example – technology choice). [Thesystem must be able to run on Windows 2000 andWindows XP.]Documentation – Describe the purpose, desiredcontents, level of detail, and formatting (User Manuals,Installation Guides, Online Documentation and HelpSystems, and Labeling and Packaging). [The systemshall provide context sensitive help that takes the userto the specific help topic related to their presentscreen.]Efficiency – How well the system utilizes resourcessuch as memory, disk space, etc. [The system shallhandle 25% more operations with existing hardwareconfigurations.]Flexibility – How much effort is needed to add newcapabilities to the product. [In addition to satisfyingall requirements to onboard vendors, the system shallallow for the addition of future vendors and/or futurelegal entities.]Hardware Interfaces – The characteristics of eachinterface between the software system and thehardware components of the system. [The systemshall have the ability to receive data from the portablebarcode scanning devices used by the shipping users.]Interoperability – How easily the system can interactwith other systems. [The system shall be able to copyfile from the source server to the destination server.]Legal – Any system constraints that are required bylaw. [The system shall prompt the user to confirmwhether or not the system will be used in any exportrestricted country as defined by the US Department ofState in compliance with the USA PATRIOT act.]Logical Database Requirements – Requirements forany information that is to be placed into a database,including data models, field types, frequency of use,integrity constraints and accessing capabilities. [Thesystem shall keep the last five fiscal quarters worth ofdata.][User accounts consist of user names,passwords, and date of creation.]Look and Feel – General requirements that capturehow the system will appear. [The User Interface willutilize web pages and adhere to the standards alreadyin place among the web-based applications.]Maintainability – How easy it is to fix a defect orchange a requirement in the system after it isdeployed. [The system will follow all IT ChangeManagement procedures when maintenance isrequired.]Memory Constraints – Any constraints on the systembased on memory usage. [The system shall utilize nomore than 30% of the available system memoryresources (minimum of 256k of RAM) at any time.]Operations – Any operations required by the user(example – application monitoring). [The system shallutilize standard manual error logging as defined bythe testing team.]Performance – Include requirements placed on thesoftware performance or on performance of the humaninteraction with the software. [The system shallrespond to search requests within 2 seconds whilehandling up to 50 transactions per second for eighthours.]Portability – How easily the system can be migratedfrom one platform to another or one machine toanother. [The system shall be designed such that itmay be moved from a Windows 2000 operatingenvironment to a Windows XP environment withoutcode modifications.]Reliability – Probability of the software executingwithout failure for a period of time. [The system shalloperate without critical failure for a consecutive 72hour period under current average loads.]Reusability – How easily a component of the systemcan be used by another system. [The system shallhave separate modules that individually can integrateinto existing order management and inventorymanagement systems.]Robustness – How well the system needs to functionwhen there is invalid data, defects, or unexpectederrors. [If the primary server is not available, thesystem shall be routed to the secondary server toperform the functions.]Security – Specify the factors that would protect thesoftware from accidental or malicious access, use,modification, destruction, or disclosure. [Any fileuploads using protocols such as FTP shall be securedusing 128 bit encryption.]Site Adaptation Requirements – Requirementsspecific to where the product will be installed (example– globalization requirements). [All timestamps shownby the system shall be translated into the local timewhere the system is installed.][The system shallsupport varying names and number of storage sites ateach warehouse facility.]Software Interfaces – The use of other requiredsoftware products and interfaces with the system.[The mainframe must accept orders from the systemthat contain alphanumeric fields.]Testability – Ease with which the system can betested for defects. [UAT must be able to be performedfrom a remote computer outside the UAT lab, as manyusers are global.]Usability – How easy the system is to use for the endusers. [The new user interface design shall increasethe speed with which users can enter purchase ordersby 30%.]
Project Name: Requirements Document (version 1.0)To use this template: 1. Replace any red italicized text with your own text. You may remove or add sections as needed for your particular projects.2. Enter the project name in the title and footer (and change the document version number, if necessary).3. If your document is very long, break each numbered chapter into its own document section, beginning it on a new page. This will make it easier to replace/updagte 4. Delete these instructions and any other italicized instructions.
Project:Date(s):Prepared by:
Document status: __ Draft __ Proposed __ Validated __ Approved
1. IntroductionThis document contains the system requirements for project name. These requirements have been derived from several sources, including brief listing of most important sources.
1.1 Purpose of This DocumentThis document is intended to guide development of project name. It will go through several stages during the course of the project:1. Draft: The first version, or draft version, is compiled after requirements have been discovered, recorded, classified, and prioritized.2. Proposed: The draft document is then proposed as a potential requirements specification for the project. The proposed document should be reviewed by several parties, who may comment on any requirements and any priorities, either to agree, to disagree, or to identify missing requirements. Readers include end-users, developers, project managers, and any other stakeholders. The document may be amended and reproposed several times before moving to the next stage.3. Validated: Once the various stakeholders have agreed to the requirements in the document, it is considered validated. 4. Approved: The validated document is accepted by representatives of each party of stakeholders as an appropriate statement of requirements for the project. The developers then use the requirements document as a guide to implementation and to check the progress of the project as it develops.
1.2 How to Use This DocumentWe expect that this document will be used by people with different skill sets. This section explains which parts of this document should be reviewed by various types of readers.
Types of ReaderIn this section, list the different types of reader this document is aimed at. For example, Flash programmers, graphic designers, end-users, project managers, etc. For each type of reader, clearly state which sections are most pertinent to them, and which may be safely skipped.
Technical Background RequiredDescribe here the technical background needed to understand the document in general, and any particular expertise or understanding that is needed for specific sections.
Overview SectionsList here the sections that should be read by someone who only wishes to gain an overall understanding of the project, or which should be read first before technical requirements are reviewed.
Reader-Specific SectionsIn this section, name any parts of the document which are intended only for one or another of the reader types identified above, and which may therefore be skipped by other readers.
Section Order DependenciesIf readers will need to read certain sections in a specific order, note those sections here. Also point out any sections that may be read independently with no loss of understanding.
1.3 Scope of the ProductInclude a brief narrative here which describes the product as you intend it to be realized. Use this section to define boundaries and set expectations.
1.4 Business Case for the ProductWhy is this product required? How will it contribute to the goals of your institution? This section can be used when requirements are being negotiated, to assess whether a particular change is a good idea. This section also helps readers understand why certain requirements have been included. 1.5 Overview of the Requirements DocumentIf your project is small to medium in size, include a summary of the requirements here. This may be a numbered list of the most important requirements. The purpose of this section is to give the reader a general understanding of the requirements and focus attention on the most critical ones. This section may also help point readers to the specific requirements that are of particular interest to them.
2. General DescriptionThis section will give the reader an overview of the project, including why it was conceived, what it will do when complete, and the types of people we expect will use it. We also list constraints that were faced during development and assumptions we made about how we would proceed.
This section contains a nontechnical description of the project, usually in narrative form, which may serve to acquaint new readers with the purpose of the project. It also sets the stage for the specific requirement listing which follows.
2.1 Product PerspectiveWhy have you chosen to develop this product? What need does it serve? Who are the primary stakeholders, who is developing the project, and who will benefit from the finished product?
2.2 Product FunctionsWhat does your product do? What activities can users perform while using it? List the main functions that you will build into your product here.
2.3 User CharacteristicsWho do you expect to use your finished product, and why? What is their technical background, their training or education, their motivation to use it? What obstacles might they encounter, and what specialized skills will they need?
2.4 General ConstraintsDid you work under any constraints such as platform or development environment? Did you have to make your product compatible with any existing software or other products currently in use?
2.5 Assumptions and DependenciesIn this section, list any assumptions you made about your project (for example, did you assume that the finished product would need to be delivered over the internet?). If your project depends on any particular technical infrastructure, or requires administrators or others with specific skills, note that here.
3. Specific Requirements This section of the document lists specific requirements for name of project. Requirements are divided into the following sections:1. User requirements. These are requirements written from the point of view of end users, usually expressed in narrative form.2. System requirements. These are detailed specifications describing the functions the system must be capable of doing.3. Interface requirements. These are requirements about the user interface, which may be expressed as a list, as a narrative, or as images of screen mock-ups.
3.1 User RequirementsList user requirements here.
3.2 System RequirementsList detailed system requirements here. If your system is large, you may wish to break this into several subsections.
3.3 Interface RequirementsList interface requirements here; or include screen mockups. If you use mockups, be sure to explain major features or functions with narrative to avoid confusion or omission of desired features.
4. AppendicesIf you wish to append any documents, do so here. You may wish to include some or all of the following:• Personas and scenarios developed for this project• Transcripts of user interviews, observations, or focus groups• Copies of communications which contain user requirements• Original project proposals or other historical documents• Lists of similar projects or products, with notes about how they differ from yours• A list of requirements which were “wish-listed” or marked unfeasible at present• Original screen mockups, if they are relevant
5. GlossaryInclude a glossary of definitions, acronyms, and abbreviations that might be unfamiliar to some readers, especially technical terms that may not be understood by end-users or domain-specific terms that might not be familiar to developers.
6. ReferencesList references and source documents, if any, in this section.
7. IndexIf your document is very large, consider compiling an index to help readers find specific items.
