Talk:Requirements analysis

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 article. -- Marcel Douwe Dekker (talk) 00:28, 10 October 2008 (UTC)

MDD, well done. I've done some work on the Use case article, also Stakeholder analysis and Scenario ... it's all in need of TLC. The removed text below is quite well-written for a piece of WP:OR - we could perhaps use it in Use case but only with citations, could be easier to start again from the sources. Chiswick Chap (talk) 10:05, 18 December 2011 (UTC)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

I agree. If you want to improve it, go ahead. -- Marcel Douwe Dekker (talk) 00:30, 9 February 2009 (UTC)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

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)

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)

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)

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)

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)

Stakeholder issues

The reference to McConnell's book is incorrect. It is unclear, if the list below the reference is taken from the book unmodified.

• If the section pretends that the list was suggested by McConnell, then it lies; there is no such a list in the book.
• If the list is a paraphrase of the McConnell's book, then it is a very far from the original text. The similar list is present in the section related to the development Risks and not to the requirements analysis specifically.
• If the list is a generalization of the McConnell's thoughts taken from 'Rapid Development', then this section represents an original research and should be marked as such. — Preceding unsigned comment added by 46.0.73.122 (talk) 21:04, 17 December 2011 (UTC)

Thank you. Obviously the section has been edited since someone put in the McConnell citation. I'll take a look at it - all welcome to help tidy up the section. Chiswick Chap (talk) 10:01, 18 December 2011 (UTC)

There's also a sentence in there, "It is also means that the requirement that's is under action process.", that is totally meaningless as written. I considered rewording it but, given that I haven't the faintest idea what it's trying to say, I found it impossible. Jgmccabe (talk) 23:32, 1 November 2016 (UTC)

Prototyping - unsourced text removed

I've cut down the Prototyping section to a couple of simple paragraphs with links to other articles (and a MAIN: link to Software prototyping). The rest of the text is below if anyone feels like editing and sourcing it. Chiswick Chap (talk) 12:24, 18 December 2011 (UTC)

Prototyping text cut from article:

"In the mid-1980s, prototyping was seen as the best solution to the requirements analysis problem. However, over the next decade, while proving a useful technique, prototyping did not solve the requirements problem:

• Managers, once they see a prototype, may have a hard time understanding that the finished design will not be produced for some time.
• Designers often feel compelled to use patched together prototype code in the real system, because they are afraid to 'waste time' starting again.
• Prototypes principally help with design decisions and user interface design. However, they can not tell you what the requirements originally were.
• Designers and end-users can focus too much on user interface design and too little on producing a system that serves the business process.
• Prototypes work well for user interfaces, screen layout and screen flow but are not so useful for batch or asynchronous processes which may involve complex database updates and/or calculations." (cut text) Chiswick Chap (talk) 12:24, 18 December 2011 (UTC)

I would like to introduce the topic of automated requirements analysis. I must be up front that I have a conflict of interest because my company has developed the first tool <<spamlink redacted>>, that automates three key aspects of the analysis of written software requirements (1. QA of requirements, 2. Functional Sizing and 3. Auto generated test cases). I'd welcome someone else to insert the copy, as I believe that I would not be permitted to do so under wiki rules. Colinrhammond (talk) 17:20, 31 July 2019 (UTC)

Proposed new section

I am the inventor of ScopeMaster, the first tool to automate several aspects of requirements analysis, so I do have specialist knowledge in this topic. One might even argue that I could have a potential conflict of interest, notwithstanding readers of this article will be interest in automation and I have quoted a couple of independent verifiable sources. I trust this is acceptable. Colinrhammond (talk) 20:09, 13 December 2019 (UTC)

As you've been told several times, your self promotion and repeated attempts to insert references to your products are not acceptable. - MrOllie (talk) 20:41, 13 December 2019 (UTC)

MrOllie|MrOllie I'd like to understand how readers of wikipedia might discover them then and why is it that other tools some of which are inferior or even defunct remain linked from widipedia? 2A00:23C5:7907:BC00:B081:644C:C530:D239 (talk) 21:04, 13 December 2019 (UTC)

Since Wikipedia is not meant to be a vehicle for advertising, readers of Wikipedia will have to discover your company on some other web site. - MrOllie (talk) 21:15, 13 December 2019 (UTC)

MrOllie, Wikipedia is surely a vehicle for sharing the latest researched knowledge? Suppression of contributions from those who are close to a topic may lead to Wikipedia becoming out of date. I know my stuff when it comes to automated analysis of requirements. Numerous world experts laud my work, but you choose to suppress it from the public's awareness. Is this a power play or do you really believe that you are serving the appropriate curation of knowledge? Colinrhammond (talk) 22:18, 13 December 2019 (UTC) 22:16, 13 December 2019 (UTC) Even Steve Mconnell who is quoted on this page has me quoted on the back of his latest book. https://www.amazon.co.uk/More-Effective-Agile-Roadmap-Software/dp/1733518215 — Preceding unsigned comment added by Colinrhammond (talk • contribs) 22:20, 13 December 2019 (UTC)

No, Wikipedia is not a vehicle for sharing the latest knowledge. Wikipedia is a vehicle for sharing widely accepted knowledge, not for promoting technology that is only sold by a single vendor. That would be advertising. - MrOllie (talk) 12:59, 14 December 2019 (UTC)

How was my contribution not neutral objective prose? Can you advise what wording might be acceptable to you? Colinrhammond (talk) 15:37, 14 December 2019 (UTC)

It was not neutral because it served to emphasize a feature of your product. I can't think of any wording that accomplishes that aim and would be acceptable. - MrOllie (talk) 16:35, 14 December 2019 (UTC)

So many products are mentioned on Wikipedia, are they not ok? For now you would prefer that the world remains uninformed about the automated requirements analysis successes that are taking place? Surely there must be some wording that is acceptable? Colinrhammond (talk) 17:35, 14 December 2019 (UTC)

The activity of requirements analysis has now been significantly automated by our tool ScopeMaster, yes I have a COI, so I am not permitted to contribute myself. But this page is out of date and lacks credibility, I'd be grateful if someone would contribute or sanction a contribution that the world has moved on from whiteboards. ScopeMaster analyses software requirements for 10 different category of attribute (five types of ambiguity, duplication, completeness, measurability, consistency, user-orientedness and traceability to business value. It would be a shame if Wikipedia does not move with the times. Colinrhammond (talk) 11:32, 1 January 2020 (UTC)

May I propose a change to the definition for consideration to: Requirements analysis describes the intellectual work involved in describing, representing and interpreting the system behaviours involved in meeting the functional requirements of the system. Colinrhammond (talk) 07:35, 6 July 2020 (UTC)