Not Signed-In
Which clippings match 'Requirements Documents' keyword pg.1 of 1

Agile Software Development: what we've learned at Forty

"The general idea behind Agile is that instead of arguing about the wording of a requirements document written three months earlier with little perspective into the current situation, it's often healthier to acknowledge that the project is going to be flexible and evolving, and put processes in place that allow it to be that way.

Barely over 200 words, that manifesto become the foundation for a movement that has changed the world of software development forever. Endless writing and speaking has explored the various ways the manifesto could be interpreted, and many specific frameworks and methodologies (such as Extreme Programming, Kanban, Lean, and Scrum) have been developed to formalize its principles. A whole 'Agile industry' has emerged, with successful companies offering tools, training, consulting, certification, and other products and services. The economic engine behind the Agile movement as a whole is massive. ...

On the surface, it seems like design and Agile should magically work together, but there are some underlying philosophical issues you have to wrestle with before figuring it out. Design is all about big–picture thinking: planning, strategy, working out all the details, thinking everything through, making it perfect, etc. (Eric Karjaluoto called it the 'masterpiece mentality.') Agile, on the other hand, is more often about doing the basics and saving details for later: iteration, minimum viable products, 'perfect is the enemy of done,' etc. Those two worlds don't blend smoothly together, at least at first. Agile developers can get frustrated with designers for over–thinking things ('Why can't they just let it go? We can get to that later.'), while the designers get discouraged by the perceived low standards of Agile developers ('Don't you want it to be good? Don't you want the user to be happy?').

In both cases, though, the problem comes from a misunderstanding of each other's perspectives (as problems often do). The designer isn't being obsessive, they're just trying to do right by the user. And the developer isn't being lazy, they're just following a process that actually gets things done with minimal navel–gazing. Both sides could learn some important lessons from each other."

(James Archer, Forty)



Simon Perkins

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)



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


Simon Perkins

to Folksonomy

Can't access your account?

New to Folksonomy?

Sign-Up or learn more.