Talk:Requirements analysis/Archive 1

To do list

I moved the to-do list here . -- Marcel Douwe Dekker (talk) 15:17, 21 October 2008 (UTC)

• Remove software bias: "system" doesn't only mean "computer system", and all "systems engineering" has requirements as an input
• Make the article comprehensive:
  • User stories
  • Business modelling
  • Graphical modelling
  • UML modelling
  • Project managements blind spot with requirements
  • Misunderstanding of what software is. Engineering and manufacturing metaphors.
  • Clarify the meaning of "Stakeholders"
• Copyedit the whole article to give it a consistent style
• Wikify
• Add references
  • Alistair Cockburn, etc.
• System level requirements can be allocated to either hardware, software, facilities, documentation (processes/procedures/manuals), personnel, or the environment.

2006 merge

On this date, this article was merged with requirements engineering. I've taken out what I thought were the most useful sections; but it might still have some useful points worth mining. :ChrisG 13:51, 27 Nov 2004 (UTC)

Why Requirements ANALYSIS? Most requirements processes have Analysis as a discrete step, after (say) Context Setting, User idenification, and Requirements Elicitation, but before Generation of Candidate solutions. A better term for this article would be R. Management or R. Engineering. Matt Whyndham 17:47, 23 June 2006 (UTC)

I agree! The article is really about Requirements Engineering. Requirements analysis is only a part of that even though the article tries to claim that "requirements analysis includes ... Eliciting ... Analyzing ... Recording" (analyzing is only one part of analysis?).

Lakeworks (talk) 00:34, 19 January 2008 (UTC)

How to or references to IEEE documents

I'm working, currently, as a tech writer doing specs (SRS, SyRS). I was wondering, would a "how to write a spec" be welcome?" i mean, i'll just further explain the IEEE STD 830-1998 and such documents. Project2501a 11:32, 27 Jan 2005 (UTC)

I don't think that would be useful because this is a generic article. It already recognises the the most common styles of contract style and use cases, because they are the most popular. I don't know the standard you are using; but if it is a common standard it deserves an article of its own. As a side note, real detailed advice on writing specifications might be suitable for the wikibooks project. :ChrisG 21:28, 27 Jan 2005 (UTC)

COOL! So, that means i'll place in my Zergling Brood Hatchery an article about the IEEE-STD 830-1998 (How to write an SRS) and IEEE-STD 1233-1998 (How to write an SySR) and a wikibook for each :D

Developer Issues

Section Developer Issues. just my 2 cents. I think this section is unjustly harsh on developers who although highly skilled in construction, testing and implementation of software should not be held responsible for lack of project management, thorough requirements analysis, systems analysis and design issues, all of which should be the domain of other project team members. All too often (at least in the USA) the developer is expected to do all of the above and gets to carry the can when it goes wrong.

Developers should take a technical design specification and business requirements and turn these into detailed program specifications, unit test scripts and code. They should not be responsible nor are they being paid to produce the above, that is the domain of the project manager, the end users and the business analysts, and perhaps the database analysts and

End users who are paying for the product should educate themselves and involve themselves more in the software development process, and take responsibility for at least knowing their own business requirements.

It seems to work much better than way in Europe than in the USA. (more disciplined approach, more planning, more testing, more documentation, maybe more boring but results in more quality)

Dmallinson 2005-07-10 15:20 PDT

216.143.182.12 12:10, 4 April 2006 (UTC)

I believe that this article attempts to tackle a very large concept with a modest amount of verbiage. I think that I would recommend paring the article down to the bare minimum to provide detail that requirements definition is the process of gathering information about what features a product, good, or service needs to be successful, and leave it at that. There are too many methods, most not mentioned in this software-centric article to satisfy everyone’s needs.

Chris Kijora 216.143.182.12 12:10, 4 April 2006 (UTC)

See Tom Gilb's Competitive Engineering for a more thorough discussion. One fundamental flaw with the entire discipline discussed here is that it does not start with Goals. To achieve superlative results, it is necessary to begin with the Goals. Requirements should be expendable if they do not contribute materially to the Goals. The entire set of Goals work best when they can be described on a single page. Good Goals are concise and subject to unambiguous numerical measurement.

A goal is a target and thus optionally hit. A requirement must be met under all circumstances and is not expendable. A statement claiming to specify a requirement which is expendable is there for an option and not properly a requirement. Consequently, I believe you have it backwards -- requirements must be met first then check to see if goals are met. Frequently, in my experience goals are used as a substitute (short cut) for proper system analysis and requirements derivation. Aspenlogic (talk) 23:11, 2 May 2008 (UTC)

The selection of requirements is a vital engineering process which involves negotiating with stakeholders. It is important to keep implementation methods out of both goals and requirements in order to give the engineers the greatest latitude in designing a successful system. A key feaature of the most successful projects is that they provide very frequent reality testing and actual improvement from prior systems at twenty to fifty (or more) evolutionary deliveries during the project. To permit anything less risks large failures after the entire budget (or more) has been expended. This catastrophe currently occurs in more than forty percent of large high-tech projects. Karpinski 18:24, 25 June 2006 (UTC)

Options can be negotiated with stakeholders, requirements cannot. A requirement by definition (See require and requirement)is indispensable. Negotiations present the possibility of elimination and hence represent the ability to dispense with something. The trick in elucidating requirements is to ensure the stakeholder(s) understand the difference at the beginning of the effort. Aspenlogic (talk) 23:11, 2 May 2008 (UTC)

Requirements analysis resources (transferred from article external links section)

The following was transferred from the External links section of the article (which I've pared down to just the links themselves). It's valuable information, but it clutters up the article, and is inconsistent with the stype of external links sections in other WP articles. I've placed the info here so that it's still available as a reference for editors of this article. --Allan McInnes (talk) 06:04, 25 April 2006 (UTC)

• Requirements Engineering Process "Goodies"
  • Author: Karl Weigers
  • Abstract: This is a set of requirements engineering templates, checklists and guides made available by Karl Wiegers as a companion to his book, "Software Requirements" (Microsoft Press).
  • Date: 2006
• Product Engineering Practices
  • Authors: Andrew Stellman, Jennifer Greene
  • Abstract: This is a page of product engineering templates and practices, including use cases, functional requirements and software requirements specification, from the companion site for their book, "Applied Software Project Management" (O'Reilly).
  • Date: 2006
• What is Requirements Engineering?
  • Authors: experts@requirements.in
  • Abstract: This is a reviewed article that explains what Requirements Engineering is and how eminent researchers have described it.
  • Date: 2006
• Adopting Requirements Visualization (PDF)
  • META Group
  • Date: 2004
• Application Definition Best Practices (PDF)
  • Date: 2005
• Requirements Engineering: A Roadmap (PDF)
  • Authors: B. Nuseibeh, S. Easterbrook
  • Abstract: This paper presents an overview of the field of software systems requirements engineering (RE). It describes the main areas of RE practice, and highlights some key open research issues for the future.
  • Date: 2000
• Guide to the Business Analysis Body of Knowledge
  • IIBA President: Kathleen Barret
  • Chair: Brenda Kerton
  • Co-chair: Kevin Brennan
  • Members: Barbara Carkenord, Gerrie Caudle, Kathleen Hass, Mary Gorman, Karen Mitchell, Cleve Pillifant, Dulce Oliveira
  • Abstract: The Business Analyst Body of Knowledge represents the unique knowledge necessary for someone to be a successful business analyst. It sets an industry standard for practice and knowledge, and is maintained by BA practitioners with input from other stakeholders. Once complete, the BOK will form the basis of the accreditation program.
  • Date: 2005
• Visualization for Start-up and Emerging Companies
  • Author: Maurice Martin
  • Abstract: This article describes how visualization is helping start-up and emerging companies improve their odds of success.
  • Date: 2005
• Guide to the Software Engineering Body of Knowledge
  • Project Champion: Leonard Tripp
  • Executive Editors: Alain Abran, James W. Moore
  • Editors: Pierre Bourque, Robert Dupuis
  • Abstract: The objectives of the Guide to the Software Engineering Body of Knowledge project are to:
    • characterize the contents of the Software Engineering Body of Knowledge;
    • provide a topical access to the Software Engineering Body of Knowledge;
    • promote a consistent view of software engineering worldwide;
    • clarify the place of, and set the boundary of, software engineering with respect to other disciplines such as computer science, project management, computer engineering and mathematics;
    • provide a foundation for curriculum development and individual certification and licensing material.
  • Date: 2001
• Writing High Quality Requirement
  • Author: Dr. Linda Rosenberg (SATC, NASA)
  • Abstract: The requirements specification establishes the basis for all of the project's engineering management and assurance functions. If the quality of the requirements specification is poor, it can give rise to risks in all areas of the project. This workshop will educate project managers and software developers in effective development of quality requirement specifications. It will also provide them with ideas and methods they can incorporate immediately into their project plan and find a productive return in documentation evaluation and comprehension.
  • Date: 1999
• Agile, Multidisciplinary Teamwork
  • Author: Gautam Gosh
  • Abstract: This article presents techniques and tools used to create requirements with a team composed of the different participants of agile projects.
  • Date: 2004

Merge from Software requirements analysis

This was suggested a while back. I support merging. The other article may have been intended as a soft redirect, but I think a hard redirect would be better. Boson 21:15, 16 September 2006 (UTC)

Reorder and condense

IMO the article is a bit "topsy-turvy", with undocumented, alleged problems and issues at the beginning, followed by the main information.

I propose moving "Main techniques" to the top (after the introduction) and moving the rest to the end, with the title "Problems" "or "Issues". Since some of the issues are now mentioned in under "Main techniques" and the some of the statements are rather sweeping, I would delete most of "The challenge", "General problem", "Engineer/developer issues", and some of "Solutions". Some of the deleted matter could be replaced with documented problems/issues, perhaps citing something like the Standish Report Can "Remove software bias" be removed from the To Do list?
Boson 21:41, 16 September 2006 (UTC)

Re-ordered and condensed

Others had also suggested major paring and editing, so I have now reordered and condensed the article. I have attempted to make it more encyclopedic and less like a text book or essay by removing some repetitions, how-to instructions and POV discussions.--Boson 21:25, 7 October 2006 (UTC)

Vandalism

Can someone ban the dude? I'm getting tired reverting the document all the time. Haw81 20:15, 10 October 2006 (UTC)