Talk:Requirements analysis

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Chiswick Chap (talk | contribs) at 17:57, 10 November 2011 (→‎Overlapping concepts: 2 quick comments). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Use case description cropped

I wikified the article and skipped most if the Use case description. I think this should be in the use case article itselve and not in this overview artcile. -- Marcel Douwe Dekker (talk) 00:28, 10 October 2008 (UTC)[reply]

Text removed

During the 1990s, use cases rapidly became the most common practice for capturing functional requirements. This is especially the case within the object-oriented community, where they originated, but their applicability is not restricted to object-oriented systems, because use cases are not object-oriented in nature.
Each use case focuses on describing how to achieve a single business goal or task. From a traditional software engineering perspective, a use case describes just one feature of the system. For most software projects, this means that perhaps tens or sometimes hundreds of use cases are needed to fully specify the new system. The degree of formality of a particular software project and the stage of the project will influence the level of detail required in each use case.
A use case defines interactions between external actors and the system under consideration, to accomplish a business goal. Actors are parties outside the system that interact with the system; an actor can be a class of users, a role users can play, or another system.
Use cases treat the system as a black box, and the interactions with the system, including system responses, are perceived as from outside the system. This is deliberate policy, because it simplifies the description of requirements and avoids the trap of making assumptions about how this functionality will be accomplished. For a better understanding, it's a good idea to review solid use case examples.
A use case should:
  • describe a business task to serve a business goal
  • be at an appropriate level of detail
  • be short enough to implement by one software developer in a single release
Use cases can be effective for establishing functional requirements for some but not all types of projects. Use cases focus on users' interactions with the system, and as such work well for end-user applications. However use-cases are much less valuable in projects where deep complexity does not lie in user interactions, such as: batch processing, data warehousing, or systems with complex computations or detailed calculations.
Use cases are not suited to capturing Non-Functional Requirements. However Performance Engineering specifies that each critical use case should have an associated performance oriented non-functional requirement.

Removed {{Software development process}}

I removed the {{Software development process}} template here, for two reasons:

  1. The template is replaced by the a new Template:Software Engineering template and will probably be removed sone.
  2. This vertical template about software engineering is confusing any way, because it pretends the article is for most parts a central part of templates subject, which is not.

The central scope of this article is systems engineering, and not software engineering so this template is not acceptable here. The alternatiev template is allready present. -- Marcel Douwe Dekker (talk) 13:06, 21 October 2008 (UTC)[reply]

Requirements analysis or Requirements engineering

I removed the openings phrase:

Requirements analysis or Requirements engineering

I don't this both are quite synonym.

It seems to me "Requirements engineering" is the study of "Requirements analysis". I think the term should be introduced and explained separatly:

  • in a separate sentence in the introduction
  • and in a separate chapter in the article
  • and then the term "Requirements engineering" can directly redirect to that chapter.

-- Marcel Douwe Dekker (talk) 15:32, 8 February 2009 (UTC)[reply]

Requirements engineering is nót a study. See Engineering. You can study requirements engineering but that's not the same as requirements engineering being a study. (Follows a longwinding treatise about "is" and "being.") Cheers. -- Iterator12n Talk 16:03, 8 February 2009 (UTC)[reply]
Requirements engineering is both a study, and a discipline and profession of applying technical and scientific knowledge concerning requirements, requirement analysis and design. You can study requirements, the study of requirment engineering seems a meta study to me. -- Marcel Douwe Dekker (talk) 19:54, 8 February 2009 (UTC)[reply]
Requirements are not engineered. Requirements are assumed or determined. Engineering either meets requirements or is a consideration in changing requirements.
One can study engineering to become an engineer. But the study itself is not engineering. Engineering may require the study of dynamics either before or during an engineering process. Studying an engineering process may lead to a better engineering process. Therefor, engineering is a process that may require study, but it's not the study itself. Hope that helps. Oicumayberight (talk) 20:46, 8 February 2009 (UTC)[reply]

Let just stick to notable sources, instead of these speculations:

  • For example Phillip A. Laplante (2007) "What Every Engineer Should Know about Software Engineering" on page 44, explains:
"Requirement engineering is a subdiscipline of software engineering that is concerned with the determining the goals, functions, and constrains of software systems.... Ideally the requirement engineering process begins with a feasibility study activity, which lead to a feasibility report... After a go/no go decision the Requirements analysis can begin."

This is just one source explaining the difference between the two terms. And that is what this discussion is about: Whether or not Requirements analysis and Requirements engineering are synonym or if there are severe differences. -- Marcel Douwe Dekker (talk) 21:07, 8 February 2009 (UTC)[reply]

Just judging by that quote, the difference is not that either engineering or analysis "is" a study, not that both can't include study. It's only saying that one includes study in it's process. What Phillip A. Laplante is calling "Requirements engineering" seems to be just a more accurate way of determining what is possible than "analysis," and that "analysis" is more speculative. To say that something "is" in the English language is almost like saying that it is "summed up by." Engineering is not summed up by study. Engineering may include study. See set theory. Oicumayberight (talk) 21:53, 8 February 2009 (UTC)[reply]
The bottum line is that Phillip A. Laplante explicitly differentiates Requirements analysis from Requirements engineering. -- Marcel Douwe Dekker (talk) 22:43, 8 February 2009 (UTC)[reply]

Marcel, here nobody is saying that RE and RA are synonyms. I was taking issue with RE being labeled a study. And Mayberight: Requirements, and particularly product requirements, may be "massaged." And if one looks very closely, even customer requirements may be re-formed - also known as the (re-)setting of customer expectations, or the management of customer expectations. Massaged, setting, managed, engineered, whatever. For requirements engineering, see also SWEBOK, the Software Engineering Body of Knowledge, the painfully imperfect but closest thing that software engineering has for a consensus opinion. -- Iterator12n Talk 22:46, 8 February 2009 (UTC)[reply]

Ditto. I don't dispute that RE is a separate concept. I would dispute that RE is summed up by a study. I would also dispute that it's a study of the analysis. Probably a more accurate statement would be requirements engineering helps determine what requirements are possible before requirements analysis is finalized. I would even mention the imperfections of this line of thinking as it is often not outside the box. Oicumayberight (talk) 23:10, 8 February 2009 (UTC)[reply]
Ok. I will make Requirements engineering a separate chapter in this article, and redirect Requirements engineering there, and won't mention it is the study of "Requirements analysis". -- Marcel Douwe Dekker (talk) 23:25, 8 February 2009 (UTC)[reply]
The way that section is worded, it sounds a bit rigid, as if there is no overlap between the RE and RA. Correct me if I'm wrong, but isn't RA the part where you determine what the client wants? It would make sense to me to determine what I wanted, and then adjust my goals once I determine what is possible. It sounds like what that section is saying is that one must determine what is possible (RE) before considering what they want (RA). Again that's not the outside the box approach. I know that may be a sourced opinion, but it still sounds rigid if no overlap was the intent. Oicumayberight (talk) 00:19, 9 February 2009 (UTC)[reply]
I agree. If you want to improve it, go ahead. -- Marcel Douwe Dekker (talk) 00:30, 9 February 2009 (UTC)[reply]
Yes, anybody, please go ahead. For me, Requirements engineering has been on my to-do list forever, sooner or later I'll get to it. -- Iterator12n Talk 00:52, 9 February 2009 (UTC)[reply]
I have put down some tentative headings in a separate topic here. I'd like some feedback before going ahead with changes.

Business Analysis Body of Knowledge

From the perspective of the Business Analysis Body of Knowledge (BABOK), Requirements analysis is just one of the many tasks that effect Requirements, after Requirements elicitation, and Requirements documentation (for example); whereas Requirements engineering is a broader term that covers all of these tasks, so Requirements management would be a better synonym. I will review the available sources and existing articles, devise a way to unpick and resolve this, and report back here. Once we have consensus on that, I'm happy to put it into action. Greyskinnedboy (talk) 08:21, 10 February 2009 (UTC)[reply]

I just noticed there exist(ed) a 2004 Wikipedia article on Requirements engineering], but it was socalled merged into this article. It seems that merge, was no more then altering that text into a redirect (which happens more often).
Maybe we can take that article as a starting point to recreate the Requirements engineering article. -- Marcel Douwe Dekker (talk) 10:57, 10 February 2009 (UTC)[reply]
Good find! That explains the confusion. These redirects without merging happen all too often on wikipedia. It's better to have more articles than it is to have excessively long articles or worse, articles that oversimplify a concept. :::Oicumayberight (talk) 20:14, 10 February 2009 (UTC)[reply]

I think the industry see 'Requirements Engineering' as a quite independent topic t requirements analysis. How does one undo the merge? — Preceding unsigned comment added by Craigwbrown (talk • contribs) 09:01, 12 January 2011 (UTC)[reply]

Requirements engineering section

Just scanning the requirements engineering section... The problem is that the section contradicts a couple of national and international standards addressing the subject area. Right now too busy but time will come. -- Iterator12n Talk 04:48, 9 February 2009 (UTC)[reply]

Well, the last sentence is my WP:POV based on the previous discussion. If that's the part that contradicts national standards, then we could just delete it. -- User:Oicumayberight 05:30, 9 February 2009 (UTC)[reply]
Sorry Iterator12n. Oicumayberight and my contributions based on that reliable source are fine. If you have new information, you should use it, and revail your (online) sources. Remarks like yours only makes us all feel very unconfortable... stating it is all wrong...!! -- Marcel Douwe Dekker (talk) 14:42, 9 February 2009 (UTC)[reply]
P.S. How much time can it takes to cite the standard definition of requirements engineering, if there is even one. In theory those national and international standards are just an other reliable source contradicting the current reliable source. This means there are contradicting opinions in the field, and not that the Requirements engineering section is wrong... in theory. So I changed the title here, which should have been neutral in the first place.

Brainstorming section

If "Brainstorming" is a mainstream technique, then there should be reliable sources available that talk about it. If there is just one book promoting the topic, then any inclusion of the technique should be minimal at best. AliveFreeHappy (talk) 21:20, 11 August 2010 (UTC)[reply]

Time for a rewrite?

Firstly I'd like to acknowledge the fine work done by authors and contributors to get this article to it's current state. I think it's sufficient to give a new requirements engineer/analysts insight into some key issues.

However, when it comes down to it this article needs some solid rework. Apart from the conflation between requirements engineering and analysis there are a number of issues. In many ways this article exhibits the characteristics of poor requirements cited by academics and industry observers and is the antithesis of what a god requirements analysis description should be.

I don't want to jump in half-cocked so I want to pose some questions to start, get a bit of discussion and then look to either some major reshaping of the content or developing a framework for continuous small improvements.

Questions

1. What is requirements analysis?

  • Is it a subset of a requirements engineering process?
From the RE Yahoo group comes this definition of a requirement;

Below is IEEE-610’s definition of requirement:

1. A condition or capability needed by a user to solve a problem or achieve an objective
2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document
3. A documented representation of a condition or capability as in 1 or 2 The above definitions separate users from software or system. We often say to install, configure systems that exclude users. The sharp distinction of boundary of software make it easy for us to see other levels of abstraction, such as agent and business levels. We must process information in the order of the level of abstraction from the most abstraction to the most concrete. In object oriented paradigm, we must know abstract class before know the derived classes.
Current software engineering text and practice donot make sharp or scentific distinctions of levels and begin with concrete levels, causing rework and failures. And we give ourselves excuses of requirements change. Requirements donot change in most cases. It is our understanding of them that keep change. The reason for which is lack of scientific knowledge to define requirements.
Example


  • Does a new Requirements Engineering page need to be (re) created?
  • Is Requirements Analysis a sub-system or sub-process of any higher level models? For example; I think it's an activity in the Business Analysts Body of Knowledge AND a process step in the Requirements Engineering (and Software engineering) paradigms.

2. Who performs Requirements Analysis?

  • Examples I can think of; Business Analysts, Software engineers, Product Managers, and Process Managers. No doubt there are more.

3. Why is Requirements Analysis performed?

  • There is a cost for doing this work. What's the benefit? Is there any variation in value and importance based upon who is doing the work? For example a software engineer is probably approaching an issue with a different focus to a process manager.

3.1 What is the contribution of good requirements analysis to business and project outcomes.

4. Where is requirements analysis performed?

  • Some examples that spring to mind include; Software houses, Product development labs, "enterprises" (i.e. large companies and give dept's.) Got More?

5. How is requirements analysis performed?

  • There are so many approaches that this article should probably only refer to schools of thought. I guess the argument around software engineering could inform this. I don't know enough to break this down into a manageable list.
  • Are there any universally acknowledged best practices? —Preceding unsigned comment added by 138.217.71.115 (talk) 05:04, 1 January 2011 (UTC)[reply]

5.1 Are there any industry controversies around approaches to Requirements Analysis?

  • E.g. Degree of forward planning needed, SSADM and Agile, System versus Business requirements, and so on. Thee is a pretty long list of opportunity for this section.

6. Industry information

  • Annual conferences
  • Requirements analysis (and engineering) journals
  • Industry bodies and reference guides

7. Anything else? —Preceding unsigned comment added by 138.217.71.115 (talk) 04:51, 1 January 2011 (UTC)[reply]


I'm just claiming this topic in case anyone wants to get in touch Craigwbrown (talk) 01:59, 6 January 2011 (UTC)[reply]

Given that all the wiki pages related to requirements are in a poor state I thought it may be better to work holistically rather than a piece at a time. I have created a workspace on a wikia site in case you want to jump across and help. http://businessanalyst.wikia.com/wiki/Wikipedia_Requirements_discussion — Preceding unsigned comment added by Craigwbrown (talk • contribs) 09:00, 12 January 2011 (UTC)[reply]

Hello, I agree with you. Feel free to rewrite the article to make it better. Pm master 19:51, 6 January 2011 (UTC)

Overlapping concepts

This article overlaps with a number of other articles and I think would be improved if it simply focused on requirements analysis. In particular:

  • Requirements engineering is a more general process and is not just another name for requirements analysis. The descriptions of the activities in each of these make this clear. The best way to address this I think is to have a separate article on requirements engineering
  • The description of the types of requirement would be best included in the article on Software requirements. That article needs improvement as it overlaps with the Software requirements specification article.
  • The discussion of prototyping should focus on how it used in requirements analysis rather than describe prototyping
  • The section on the software requirements specification should be deleted and should simply refer to the related article

Iansommerville (talk) 15:47, 10 November 2011 (UTC)[reply]

Ian, yes, I looked at the nest of overlapping, muddled stuff and agreed with Craig that it was... a daunting task. All your suggestions are (of course) spot on. Wikipedia has a "Be Bold" policy, so why not just do it? Come to that, I think I'll delete the SRS section now - Ian. Chiswick Chap (talk) 16:29, 10 November 2011 (UTC)[reply]

Have put a draft for comment of an article on requirements engineering here User:Iansommerville/Requirements engineering. Then section in this article should be deleted Iansommerville (talk) 17:15, 10 November 2011 (UTC)[reply]

Ian, two quick comments:

a) the waterfall model is rightly critiqued but without saying why. We could say something like: "The waterfall lifecycle is risky as it assumes you can get the requirements and design right in one iteration. More likely, projects need to trade off different choices, so the requirements are not known until the trade-off stage is complete. Hence, requirements, like design and test, will often need to be defined in successive stages." (I'm sure you can word this better.) The statement in the draft that RE continues throughout system life is true, but people will take it as meaning that requirements continue to be referenced, traced, verified - but are still all discovered up front as in the waterfall, and are then static.
b) The 'See also' section is long and structured only alphabetically. You've already provided a better structure for some of them in the list of RE activities (so why duplicate those...). It would be nicer to write a short section, maybe called 'The Context of RE', maybe using a table to provide a 2-D view of the lifecycle (time x activities?), to give an overview of how the concepts fit together. 'See also' is a bit of a 'Miscellaneous' bucket!

Hope this helps... Chiswick Chap (talk) 17:56, 10 November 2011 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Requirements_analysis&oldid=460000000"