1: Use cases and requirements
Another classification of requirement categories
-High-level requirements or vision or user requirements: unstructured, natural language with some diagrams -System requirements or more detailed requirements: more structured description of system functions and services. Can serve as a contract between client and developer. Natural language, structured language, simple mockups, data flow diagrams, charts -Software specifications: more detailed SW description to serve as basis for design. Used by developers. Natural language, block diagrams, formulae, program design language (PDL), flow charts, data flow diagrams, mockups, structured language, database schemas etc. (Exact formats and naming conventions often dictated by company policies)
High Level Requirements for User Interface - what to cover
-UI style -Platforms and standards (browser, client OS, screen size etc.) -Consistency with other playroom SW -Key screen contents -Use of media, graphics, logos, colors, branding -Screen behavior -Appearance -User interaction techniques -Response time -Navigation features -Saving data etc. -Legacy data issues -Support, training, help -Error handling -Accessibility features -Localization, Internationalization
High-Level requirements: how should they be written?
•High-level: focus on WHAT not HOW. Write from "outside-in" perspective •Leave design decisions (HOW) for later •Use SHALL for must do, SHOULD for optional •One concept per requirement •Cover all necessary issues •Avoid jargon •Number them for tracking •Group by priorities then by actors/subsystyems •Talk in positive logic •Details added as we go to lower-level requirements •Not appropriate high level requirements: -Function X shall be provided by two buttons in upper left corner, and system should be fast. -Why?
Use Cases what should use cases measure?
Task name, description and current duration as well as frequency of usage User skill level, experience and role Work steps including usage of other systems System features, GUI screens currently used difficulties and errors in using current system current systems performance and reliability follow up questions current user satisfaction
How to develop requirements regarding content organization
This is information/data design issue not a coding issue •Interview current owners and users •Base it on search needs of users as well as nature of the content (common ways of describing content) •Look at similar other products or applications •Review legacy (current usage) •Follow legal rules on content usage •Application dependent: •Movies •Stock photo •Books •Shopping
Use Cases: methods for gathering information how would you gather data?
ask users (single or team) Observe users in their actual environment Look at user documentation or any other information Survey, focus groups Ask your own marketing, sales, support, client reps Read WWW, product reviews Ask friends
Use cases: One of the most powerful methods (must do) what should use cases describe?
define actors in the application - persona - a model of a typical user e.g. define user skill level, pain points... Describe user tasks and errors Describe user environment and context Describe or use data items from data glossary - be consistent.
Use cases
services and functions personae will use in your envisioned system.
Typical Competitive features table
table of features with competitors on top row features on left columns -, +, ++ in comparing features from ours to competitors
Focus groups - Essential tool in developing requirements in UCD
•"In usability engineering, a focus group is a survey method to collect the views of users on software or a website. This marketing method can be applied to computer products to better understand the motivations of users and their perception of the product. Unlike other methods of ergonomics, focus group implies several participants: users or future users of the application. The focus group can only collect subjective data, not objective data on the use of the application as the usability test for example." •Focus groups can review use cases, ideas, mockups in addition to working code
Issues and problems with requirements (2)
•Ambiguity: can be interpreted (and will be interpreted) differently by different people or groups. •Incompleteness: do not specify all what needs to be specified. (Authors assumed that others know too much) •Conflicting •Hard to verify •Hard to use formats and document management •It is very hard to create perfect requirements. Don't try to be perfect, be good enough for product to succeed! •Requirements are only means to an end (I.e. successful product)
Usage of use cases who should be able to understand use cases? what are it's uses?
•Communicates vision of the system easily understood to non-technical people (CEO, marketing, sales, investors) •Drives the design and requirements •Use to test all aspects of the system, especially the UI •Use to develop QA plans
Waterfall and other models that required all req. to be known ahead of the time: some history
•David Parnas, Paul Clements, 1986: -A system's users seldom know exactly what they want and cannot articulate all they want -Even if we could state all the requirements, there are many details that we can only discover once we are well into implementation -Even if we knew all these details, as humans, we can master only so much complexity -Even if we could master all this complexity, external forces lead to changes in requirements, some of which may invalidate earlier decisions
Steps in req. solicitation
•Define requirement gathering methods (focus groups, meetings, interviews...). •Identify key stakeholders and users and involve them •Define technical environment for the system (architecture, OS, connections....) •Business and marketing analysis •Use case analysis •Develop requirements: •Uses cases to functional specs and data glossary •Constrains and business/marketing issues to nonfunctional specs •Document in Marketing Requirement Document (MRD)
Typical Content of a General Requirement - Text
•Description of service, function or constraints to be achieved •Use case (or reference to it) •Error conditions, special cases •Measures to verify •For data glossary: name, description, usage, behavior, storage
Software Requirements what is it? what is the focus?
•Descriptions of a SW system - starting point for specifications, design and implementation •One of the main and early component in any SE process - focus is on WHAT not HOW •Main vehicle of communication between: -Idea initiator and the rest of the world -Clients and SW providers -Customer and product development (SW, marketing, sales) -Product development and management -Product development and marketing -Between developers (especially at different locations) -Developers and QA Good overview
Functional requirements are prioritized
•Details will be covered later but the key is to prioritize functions •Helps project planning •Helps UI design - high priority functions deserve more prominent UI exposure
Non-functional requirements (3) are they determined often as technical or non-technical constraints?
•Determined often by nontechnical constraints: •Business needs •Legal, marketing, copyright •Not prioritized - they are all required •Can not be changed solely by eng. team - change requires all stakeholders
Why are simple wire diagrams best in early stage?
•Easy to produce (can be hand drawn too) •Easy to change (no coding invested) •Allow easy scribbling, markup •No graphics or colors help focus on key issues: function and layout •Allow considerable "scenario and usage" testing • (Many great designs done on a napkin...)
Issues and problems with requirements for SW
•Full requirement set is almost never known at early stage •Requirements most often change in the process due to real reasons (people learned more, business changed, users requested it after evaluation) and some other reasons (marketing wants more, competition is there, miscommunication) è recall why it is hard to manage SW projects.... •We will address this in the class (e.g. this is why Waterfall method does not work) •This is one of the key problems in building and managing large SW systems
Req. Categories: Functional and Non-functional Requirements
•Functional requirements -WHAT DOES IT DO? Services and functions system provides. How will system react and behave depending on inputs. Specific functions provided to the user. Key data items •Non-Functional requirements -HOW DOES IT DELIVER? Various constrains on timing, cost, ease of use, standards, security, performance, capacity, HW/SW environment, privacy etc. •In some cases: Domain requirements (in case of certain app domains) -Comes from application domain and reflect specifics of that domain -Key in mutidisciplinary projects e.g. bioinformatics
Priorities and specs
•Functional specs •Critical to prioritize •Priorities used to guide the design and decisions what to keep/drop/add •Helps plan the development (focus on priority 1 first) •Grouping by priorities (especially Priority 1) helps better understand what the product features are •Nonfunctional specs •Usually fixed and given by funding client/management/legal/marketing •Generally not prioritized - all must be done •Can not be changed solely by engineering team
High Level Use Cases for User Intensive Systems
Starting point. •Covered before - also: important to defer specific UI decisions to later - focus on WHAT users want to do and not HOW (HOW will be done later - mockups, prototypes, feedback...) And also •Summarize typical users by set of fictitious "personas" with their characteristics important for the application
Personas
Personas go over scenarios (use cases) using your application in the appropriate context (home, on the road...) personas have: attitude, skills, limitations, pain points, goals.
Functional requirements (2) what should we include under data description?
Data description: Describe key entities and data items and give them unique and meaningful names -Main actors/users in the system (admin, customer...) and their roles -Key data elements (book item, shopping cart, registration, search metadata). Important to describe digital content (see next slide) -For each have the name, sub-items, means of input/initialization, usage, storage etc. - •Use these names consistently for documentation, UI, reference, naming of classes and variables, database schema Proper data description is the key for communication and understanding between/among developers and clients
Use cases level of detail: High level what is HL use cases? what should HL focus on? should HL use cases be based on user needs or constraints of the system?
Focus on what the user does at high level (no details of how) HL use cases are critical: Drive them by user needs not the constrains of the envisioned system. Compromise only if you must, be a user advocate Focus on what user needs not how to design or implement
Functional and Non-functional Requirements
Functional requirements: •Functions: Describe functions and services that system provides •Also: Data description: describe key data items and entities in the system (non compulsory but extremely useful) Non-functional requirements: •System requirements: describe the system requirements (architecture, system services, networks, platforms etc.) •Usability requirements: describe specific usability and UI issues, users who will use the system, delivery clients •Performance requirements: describe system performance (speed, accuracy, latency, delay, bandwidth etc.) •Storage, security, environmental requirements •Marketing, legal requirements (logos, branding, licensing) •Content (size, formats...) •Privacy (what data is collected, how is it used...)
Functional Requirements (1) when writing up professional functional documents, what type of wording should we use?
Functions: Describe functions and services provided by the system Use SHALL Not: will, may, should... •Examples: -Users shall be able to search using image categories -Users shall be able to purchase music files using credit card -Music shall be accessible by author and title Note: may contains some usability requirements (in choices of functions available), but usability can be addressed also in non-functional requirements too)
Competitive analysis
In design of any system one needs to know •Goals and objectives •Competitive landscape - who is doing something similar •Relationship of your planned product with current market leaders Developed as competitive analysis (jointly with marketing) All CEOs, managers and investors ask this up front
Use cases level of detail: lower level what is the lower level?
More details, spell out functions, steps, etc. (less used)
Personae Vs Use cases
Personae describe who are the main actors Use cases tell a story of what services/functions users will need, in plain english.
Priorities
•It is critical to have priorities attached to each requirement so you can make choices when schedules and costs and resources get constrained •Agree on priorities with marketing, executives and customers •It never happens that all features are equally important -Priority 1: Critical: do not launch product without it. -Priority 2: Important: it would be really good to have it. Don't delay ship date if not available -Priority 3: Opportunistic: nice to have. Candidate for next release. •When it comes to cutting functions/SCOPE (always happens late in the schedule) use priorities to make a decision •Only used for functions to be provided, not for data glossary or non-functional requirements
bad high level use case
•Mary wants to search for environmental issues. She goes to our site, types "Golden Gate" in yellow search button which is upper right corner of the site, hits GO button then goes to the list of search results presented at the bottom of the screen in two columns Too many UI design details (underlined) - it is too early for this! Better one (leaves UI design details for later) •Mary wants to search for environmental issues. She goes to our site and searches by park name e.g. "Golden Gate" then reviews the list of search results
Requirements for Media Rich apps (almost all today)
•Raw data: Files used to render content (MPEG, PDF, JPEG etc.) •Metadata: data describing content, used for searching •Supporting data: data used to display items in the search result list. In the form of text, but also may include key frames, samples, previews •Price •Copyright rules Used to design both search as well as database organization Requires close interaction with data owners, librarians
Non-Functional Requirements what are they measured from?
•Refer to system properties and constraints such as: -Reliability -Response time -HW and networking requirements -Usability requirements -Marketing, legal, licensing -Media content (formats, size...) -Privacy: what is the data collected, how is the data used -Compatibility (e.g. which browsers...) - -Can refer to: -Product (product behavior like speed, reliability) -Organization (e.g. process, standards used) -External factors (e.g. branding, legal disclaimers displayed)
Requirements solicitation - gathering requirements
•Requirement Solicitation/elicitation: Process of gathering requirements •Issues •Scope - boundaries of the system to be built •Understanding - customers do not understand it either •Changes - requirements change in time (better undemanding, changing business/competitive environments, costs, schedules) •Cost effective methods of gathering - interviews, meetings, focus groups, marketing research....
What are Requirements
•Requirements: Abstract statements or descriptions of SW services, functions or constraints • •For high-level requirements focus is on WHAT not HOW •Level of abstraction goes from high (usually called requirement definitions) to more detailed (usually called requirement specifications)
Requirements what are requirements? what are functional requirements? what are non-functional requirements?
•Requirements: developed from use cases, usually by marketing, engineering, sales (focus on WHAT not how): •Functional (what functions the SW has, what does it do) •Non-functional - what properties the SW has (security, privacy, performance, deploy in Cloud? etc.)
Requirements for UI and User-Intensive Systems
•Similar rules apply PLUS: -Strongly driven by use cases and types/categories of users - personas -Considerations related to usability, inherent characteristics of intended users and UI design principles -It is very hard to communicate and specify such requirements only with text - users need to see it before they can understand or decide è use of graphical mockups and storyboards is essential (with some text please)
From Use Cases and Personas to High-level Mockups, storyboards
•Simplified graphical representations of envisioned UI •Focus is on UI basics: functions and behaviors, layout, flow •Graphics none or very minimal so as to not grab the attention •High level mockups are best B&W! (Color distracts from UX analysis) •Text description for all functions and main issues •Format: wire diagrams, HTML, hand drawings, animation •Mandatory for UI requirements and specifications
Specification
•Specifications - more concrete engineering guidance of HOW to develop the SW (often combined with requirements into SW requerment specifications - SRS)
User-Centered Design and Development
•Think of total user experience including: -Product packaging, -Ordering, registration -Installation -Help and docs -GUI itself, mainly functions, simplicity, aesthetics, responsiveness, reliability etc. -Support -Upgrade and legacy issues -Uninstall è Need to address all this in requirements
Typical Content of a General Requirement
•Title •Reference number (for tracking) •Text (a few lines or a few paragraphs) •Graphics, diagrams (optional), mandatory for UI •Initiator, owner •Priority e.g. 1, 2, 3 (can be assigned early or later) Many companies have their own templates (government, military, IEEE, ACM) Follow the required process (or work with management to improve it)
WHAT vs. HOW
•WHAT: what do you want, what the users want, what is the ultimate goal...è used for high level requirements, specs •HOW: how to do this, how to design this è for lower level, more detailed specs, design, implementation •Ideally, first focus on WHAT then on HOW •WHY? •What happens if you do HOW too early?
