Not Signed-In
Which clippings match 'Requirements Elicitation' keyword pg.1 of 1
19 JULY 2014

Using OneNote for gathering design project requirements

"Having a laptop open in a research interview puts a barrier between you and the person you're interviewing, and the typing can be quite distracting and intimidating for the interviewee. But typed notes are searchable, making for very useful reference when you're synthesizing your notes. OneNote is a nice compromise. With a Tablet in slate mode, we remove the physical barrier of the laptop, and as long as you have the pen in a 'Create Handwriting' mode, you can later go back and search your notes as if they were typed. (The handwriting recognition is pretty amazing.)

We sometimes have interviews by phone, and in these cases we often type notes. OneNote can go back and forth pretty seamlessly between handwriting and text, so it keeps all notes in one place. Also I find the quick–keys for adding tags to notes to be very useful when typing. You can tag questions you have, comments for follow–up, and ideas you generate, all with the quick stroke of a key.

For really important meetings, we can also use the audio recording features, which gives the ability to later go back and click on a piece of handwriting to hear what was being said at the time. Unfortunately you have to be using an external microphone for this, or all you hear is the tap–tap–tapping of the stylus hitting the slate surface instead of insightful interview conversation.

And I should note that research is not where OneNote shines the most. There are a few competing tools, like the LiveScribe Echo SmartPen and even pen and paper and that are giving it a run for its money. But as long as we're outfitting our designers with the Tablet, OneNote is a fine tool to use during research."

(Chris Noessel, 7 March 2013, Cooper Journal)

1

TAGS

audio recording • client interview • client liaisoncontent integration • content integration tool • design businessdesign objectivesdesign plandesign projectgeneral grounding document • handwriting • handwriting recognition • interaction design • Livescribe Echo Smartpen • managing design • Microsoft OneNote • multimedia toolnotebooknotesnotetakingpen and paperpersonas (UCD) • project reference • project requirements • requirements capture • requirements elicitationrequirements gatheringresearch interviewscope of practicesearchable content • slate mode • synthesising information • Tablet PCtext recognition • typed notes • user storiesvideo documentationworkflow toolworking practices

CONTRIBUTOR

Simon Perkins
22 OCTOBER 2013

Project Management and Business Analysis Guides

"The Project Service Centre (PSC) role within CSU is to establish sound Project Management (PM) principles throughout the organisation. This will provide a means of clearly identifying the true needs of the University and help facilitate those desired outcomes.

To achieve these objectives, the PSC must provide and enhance the methodology for project management and business analysis, including guides and templates. This particular section concentrates on a set of guides which recommends how different processes can be undertaken."

(Charles Sturt University)

TAGS

enefits analysis • brainstormingbusiness analysisbusiness analystbusiness communicationbusiness logicbusiness management • business process modelling • Charles Sturt University • conducting meetings • cost estimatedecision makingdocument analysis • echnical specification • elicitation practices • elicitation process • engineering process • financial analysis • focus group • functional decomposition • gathering requirements • interface analysis • interviewingmodelling and prototyping • needs analysis • PowerPoint lectureproblem-solvingproject managementprototypingquestionnaire • requirements analysis • requirements elicitationrequirements engineeringrequirements gatheringrequirements process • requirements workshop • reverse engineeringrole playingshared practicessoftware engineering • stakeholder interviews • surveysystem requirementsuse casesuser activity data • user observation • workshops

CONTRIBUTOR

Simon Perkins
26 SEPTEMBER 2012

Writing a Requirements Document For Multimedia and Software Projects

"Requirements include descriptions of system properties, specifications for how the system should work, and constraints placed upon the development process. Generally, requirements are statements of what a system should do rather than how it should do it. The answers to how questions fall into the realm of design. Requirements specifications should not include design solutions (except for interface requirements, which often include embedded design).

Requirements come from end users, from customers, and sometimes from developers. End users tend to state requirements in descriptive or narrative terms ('I'd like a welcome screen with links to the things I use regularly, and I want to be able to select from a couple of different color schemes for the welcome screen') which might need to be broken down into individual requirement statements. Customers, who may well be different from end users, are the people who are paying for the development of the system. Their requirements will often be stated in terms of costs or scheduling issues. Developers might have requirements related to system performance and other technical topics.

It's important to have all these groups contribute to the requirements document to create a fuller description of the system. The practice of including these groups also helps to ensure that everyone is in agreement about what is to be done before development begins.

Requirements documents usually include user, system, and interface requirements; other classes of requirements are included as needed. User requirements are written from the point of view of end users, and are generally expressed in narrative form: The user must be able to change the color scheme of the welcome screen. System requirements are detailed specifications describing the functions the system needs to do. These are usually more technical in nature: The system will include four preset color schemes for the welcome screen. Colors must be specified for the page background, the text, visited links, unvisited links, active links, and buttons (base, highlight, and shadow). Interface requirements specify how the interface (the part of the system that users see and interact with) will look and behave. Interface requirements are often expressed as screen mock–ups; narratives or lists are also used."

(Rachel S. Smith, California State University Center for Distributed Learning)

1

TAGS

business logic • business needs • California State University • design solutions • desirable requirement • documented characteristic • expressed in narrative form • functional explanation • functional requirement • functional requirements document • in scope • interface requirements • mandatory requirement • non-functional requirement • operational narrative • optional requirement • out of scope • performance qualification • planning document • prioritisationproject requirementsproject scopequality assurance • requirement statements • requirements document • requirements documentsrequirements elicitationrequirements gatheringrequirements prioritisationrequirements processrequirements specification • requirements specifications • software development process • software engineeringsoftware system • specific needs • system constraints • system properties • system requirements • user acceptance testing • user requirement specification • user requirements • user requirements document • validation process

CONTRIBUTOR

Simon Perkins
14 APRIL 2011

Scrum and Extreme Programming: User Stories

"User stories are one of the primary development artifacts for Scrum and Extreme Programming (XP) project teams. A user story is a very high–level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it."

(Scott W. Ambler, 2009)

Fig.1 User story card (informal, high level).

Fig.2 User story card (formal, high level).

1

2

CONTRIBUTOR

Simon Perkins
Sign-In

Sign-In to Folksonomy

Can't access your account?

New to Folksonomy?

Sign-Up or learn more.