- Mehdi Dadkhah asked a question:Software Requirement engineering lesson
I need slide of "Software Requirement engineering lesson". i need slide for each chapter. have any one it?Following
- Marelis Virgen Pérez added an answer:Is anyone interested in Requirement Engineering (Pattern to Requirement Statements)?I am starting a RG Project to work through an example for developing an approach to using requirement pattern concepts, UML profiles, and a UML CASE tool to generate requirement statements.
If interested please let me know, this will be open to anyone who wants to participate, or check on our progress,
I'm working on the topic of how to prioritize non-functional requirements for critical software, anyone can help me????????Following
- Ken Robinson added an answer:Is it possible to do a software cost estimation before requirement collection?Software development is a big issue in the price of the software. For example, say someone asked how much money it took to make a shop management software (or any software). They did not say anything about this software but asked only how much it cost (without requirement). But what could be the answer, because without the necessary information it can't be answered. In the case of software development many have a cost estimation but have no way to do a software development cost estimation without requirement collection. Is this also a problem you have come across? What is your advice on this situation?
Let me add a comment that doesn't strongly depend on the process used, or alternatively perhaps the process doesn't matter.
I don't have recent data, but not that long ago somewhere around 85% of very large software projects (we're talking $multimillion) failed due to failure to satisfy the requirements. Essentially this means that many projects proceed without precise requirements; most likely some vague ideas about what is required. Further, requirements are informal, but there satisfaction needs to be able to be verified in the implementation. The latter is, of course, usually not done effectively.
It seems to me that this can only be effectively done using rigorous, formal verification. But that is rarely done. For a technique that could be used, see Event-B.Following
- Dario Russo added an answer:Is there a good open-source software for requirements analysis for linux?I'm searching for some tools that help me to formalize the analysis, something more than just an UML editor.
In the end I did the requirements analysis by myself without the use of any software.Following
- What is your favorite definition of the term "requirement"? There are so many subtly different definitions out there. Which one is your favorite? And why? Because it was «first»? Because it is «best»? Let's create a word cloud from all unique answers!
Michael and Jose, I added your choices to the word cloud from above. Hope to see more votes :-)Following
- What is your opinion on the use of business vocabularies (glossaries) in various information systems/software projects? As you may have noticed, inclusion of business vocabularies (also referred to as glossaries) into the project activities is trending, yet this process is often lacking objective feedback and consolidated opinion from the experts and industry. Do we really need specialized/additional solutions for that? If you are working in the field of business analysis, business modeling, requirements engineering, IS design or development, I would like to hear your opinion!
Or better yet, please consider filling out an anonymous five minute survey that is being conducted by the Center of Information Systems Design Technologies of Kaunas University of Technology and is available at
On the last page of the survey, there is an option to leave extended feedback, if you wish to do so. Each answer is extremely valuable to us!
We would appreciate your response by March 24th. Feel free to also forward it to your fellow colleagues, both academicians and practitioners. And big thanks to all of those who have already contributed!
I must also add that this survey is part of research that we plan to publish in the form of a paper, if we get enough feedback (which is harder to achieve than we thought). So you will be the first to know when it happens!
Have you already published the results?Following
- What software tools are used to generate test cases from requirement specification? What are the software tools that help a tester to generate test cases from requirement specifications?
Maybe some tools from Test driven development http://www.agiledata.org/essays/tdd.html#Tools
I've used selenium.Following
- Does anyone have a paper referencing that the software cost estimation is a problem before requirement collection? The paper said that the need for the collection of software cost estimation is a problem before.
Hello! Does this question have been solved? It looks like interesting such hypothesis, a priori I guess that software cost estimation is impossible without requirements, how can you define a cost if you don´t know what are you going to do?Following
- What are the early cost estimation techniques used for software cost estimation? I want to know about the cost estimation techniques used in software cost estimation at present. What are the early, immediate, instant or emergency cost estimation techniques?
I guess "early, immediate or instant" cost estimation is very difficult. The faster way could be techniques like poker planning in Scrum methodology, but more accurate estimations I've done are using project data acording PSP framework. There are some tools like costar (http://www.softstarsystems.com/) who use cocomo II, but require more experience....
I guess today no one have a silver bullet for software estimation, like chaos reports from standish group states, there are almost 30% of projects failing because of requirements.... and if requirements are poor, poor the estimations too.
Function points also are a common and quick way to estimate software cost.Following
- Are there rules (semantics) that can be used to derive implicit requirements given explicit requirements of a domain? How can we learn them (Implicit Requirements)? Are there mechanisms or a set of steps that we will need to follow such that if A follows that step it's going to produce Implicit Requirements and If B follows that same step, it will end up with the similar Implicit Requirements?
I agree with mr Fannader, when eliciting requirements one should foucus all the effort in user needs, and as stated in the swebook chapter of requirements http://www.computer.org/portal/web/swebok/html/ch2, using a matrix to match each requirement with typical NFR or a requirements dependency tree to see if all the needs are covered.Following
- What are the most successful approaches to privacy requirements engineering?
Data flows modelling and analysis, risk and impact assessment, heuristics, etc. are some approaches proposed in the literature to elicit privacy requirements. There are pros and cons for all of them so, what approach do you think is the best and why? Any widespread (methodological) solution in the industry (not just at research level)?
Time ago we implemented ISO 27k at a government agency. Concerning with privacy the approach used was risk and impact assessment, we had a lot of hard work defining what the heck was private or not for each business unit, a process called "data labeling" was conducted, and at the end some agreements were done about how to treat data among the different business processes. Even contracts were redefined, everyone had to accept new conditions about handling their own work data.Following
- Nadine A. Gund added an answer:What are the top journals and conferences for software engineering, specifically requirements engineering?
Journal and conference impact factors.
- François Christophe added an answer:How can we uncover Implicit requirements in a stated explicit requirement?Is there a methodological approach that can enable us extract possible implicit requirements (Unspoken or assumed) from a requirement document?I want to believe it's possible to use linguistic metrics (e.g. G. Lami with QuARS) to find out if a requirement explained as a sentence written, say for example, in English contains implicit meaning potentially hiding tacit knowledge.Following
- Maya Daneva added an answer:Can anyone point me to the best papers describing 'non-functional' or 'soft' requirements please?I'm interested in the link between knowledge elicitation and requirements analysis/elicitation and, in particular, the role of 'soft' or 'non-functional' requirements.Following
- Today there are a lot of RE tools, but a small number of them use fine - gained use case specification. Few of these tools support transformations from use case models to another analysis or design model. What is your opnion on why?What would such a fine-grained specification entail? A UML Use Case Model? A textual description as introduced by Jacobson? Or the more elaborate forms of e.g. Constantine or Cockburn?Following
- Who coined the term "non-functional requirement"? The currently earliest paper I found containing the term is by Yeh and Zave (1). In (2), Zave speaks of non-logical properties.
(1) R. T. Yeh and P. Zave, “Specifying software requirements,” Proc. IEEE, vol. 68, no. 9, pp. 1077–1085, 1980.
(2) P. Zave, “A comprehensive approach to requirements problems,” presented at the Computer Software and Applications Conference, 1979. Proceedings. COMPSAC 79. The IEEE Computer Society's Third International, 1979, pp. 117–122.
(3) J. Mylopoulos, L. Chung, and B. Nixon, “Representing and using nonfunctional requirements: a process-oriented approach,” IEEE Transactions on Software Engineering, vol. 18, no. 6, pp. 483–497, 1992.
Am I on the right path? Different suggestions are welcome.@Ina: My hope was that it would help to understand the original intended meaning of the term.
I found the term awkward in the first place, let me draw an analogy. It occurred to me like calling all vehicles apart from cars, "non-cars". So bicycles would be classified as "non-cars". I was wondering where the dichotomy functional/non-functional came from and why it seems nobody criticized it. Boehm in 1976 already mentions the term "quality requirement" which would be a more appropriate term, but then the argument would start NFR != Quality Requirement and so on.
Maybe the answer is, simply put, that it does not make so much of a difference if the commonly accepted taxonomy of requirements is well-designed.
I currently assumed that Yeh took the term from somewhere and used it for his publications. Looking at the below cited publication, my assumption is that he wanted to point out that there are many more classes of requirement than functional ones. For that purpose, I guess using "non-functional" is exactly right.
R. T. Yeh, “Requirements Analysis - A Management Perspective,” presented at the IEEE Computer Sixth International Computer Software and Applications Conference (COMPSAC), 1982, pp. 410–416.
And a final question to Ina, again: Can you elaborate why it would make a difference to discuss NFR in different scopes? Would the definition change then? My understanding was that the definition is domain-independent. E.g. from van Lamsweerdes textbook : "Non-functional requirements define constraints on the way the software-to-be should satisfy its functional requirements or on the way it should be developed." Exchange the term "software" with "product" and you obtain a general definition.Following
- Edgardo Luzcando added an answer:Non functional requirementsCan you provide references of publications on how to find out and define non functional requirements at the requirements elicitation stage? Is there any IS development methodology that deals with this aspect?I suggest taking a look at material from the Software Engineering Institute at Carnegie Mellon, which has excellent guidance pertinent to Non Functional Requirements and the field of Software Architecture. circa 2008, though some of the original ideas are from the late 1990s. I have found it to be invaluable and effective for system design over the last few years.Following
- Matteo Merialdo added an answer:Does anyone have any suggestions for tools that handle boilerplate requirements writing and management?In the requirements engineering field, the use of boilerplates is a way towards controlled natural language.Dear Nawel, I'm writing a tool for automatic building of Goal models from NL requirement documents. I found DODT very interesting, but I can't find anything else except that document you posted here: can you suggest me were to download the tool or the source code (or any other document)? Many thanks!Following
- Nawel Amokrane added an answer:Proposed process to normalize a statement - comments?I am currently working on a process to take a statement (e.g., a paragraph from a PWS (Performance Work Statement - part of a government software development contract) and engineer the sentences into a series of "engineered" statements.
The process would be (for each statement in the paragraph):
1) Separate each sentence onto it's own line.
2) Standardize the terms using the project or domain's structured business vocabulary (SBVR).
3) Deconstruct the sentence into standalone sentences (e.g, ... and ...) being aware of implied structures (e.g., for government staff and consultants - government staff, government consultants).
4) Reword 'gently' to standardize sentence forms.
... etc.Do rely on a domain vocabulary for standardizing the terms, how do you map the un-standardized terms to standardized ones ?
are you using any NLP techniques ?Following
- Nick Battle added an answer:Can someone share information on combining semi-formal and formal methods to specify Object oriented Systems?Looking for a set of specific Problems to work on for my doctoral workFollowing
- Maya Daneva added an answer:Who defined the term 'requirement' for the first time?Does anyone know who the first (systems-, software-, ...) engineer was to coin this term? Merriam-Webster says the term has been around since 1662.
I will soon be looking at the paper titled “Conceptual models for determining information requirements” by J. C. Miller, 1964, but I don't know if this is a match yet.
The first software engineering paper to implicitly define the term was presented by Royce in 1970.
W. W. Royce, “Managing the development of large software systems,” presented at the IEEE WESCON, 1970, pp. 1–9.
The first software engineering paper to dedicate a section to the term was the one by Bell and Thayer of 1976.
T. E. Bell and T. A. Thayer, “Software requirements: Are they really a problem?,” presented at the 2nd international conference on Software engineering, San Francisco, California, United States, 1976, pp. 61–68.
Do you know earlier ones?Following
- Antoine Cailliau added an answer:What models/proposals/framework do you know to evaluate quality on modeling languages?The aim of the question is gather from your opinion the models/proposals/framework which are used to measure/define a certain quality level of modeling language for requirements engineering. So far I have a few ideas like QM4MM to evaluate the maturity of the metamodels of these languages or SEQUAL (ant works of Krogstie.)At last RE conference in Rio, there were a workshop for comparing requirements modelling approaches. This workshop was the third one and the two first were held at MODELS and focused on comparing modelling approaches.
A common case-study has been modelled in a wide variety of modelling language. Based on such common modelling, it makes the comparisons a little bit easier. The comparisons made during the workshop, and published in proceedings, are based on a set of comparison criteria covering a large set of features. Comparing modelling approach is sometimes tricky, especially when addressing different issues or with different focus.
It might be interesting to start by reading their work. See http://cserg0.site.uottawa.ca/cma2013re/ for more informations about the workshop.Following
- Antoine Cailliau added an answer:What are the key features that characterize implicit requirements?Implicit requirements are the hidden or assumed requirements that a system is expected to fulfill though not explicitly elicited during requirements gathering.Implicit requirements can be elicited through a quite large set of techniques (from checklists and guided interviews to formal analysis). I'm not sure what you mean by "key features that characterize" but here is my opinion about missing requirements/assumption/properties identification.
For a good overview of available techniques about requirements elicitation, I would recommend reading [Lam09], especially the Chapter 2. It "briefly" describes techniques such as background study, data collection, questionnaires, grids and card-sorting techniques, storyboarding, scenario-driven strategies, mockups and prototypes, interviews, observations, group sessions, etc. I think all these techniques helps in understanding the domain, and eliciting requirements.
For model-driven requirements engineering techniques, there is also a set of systematic techniques. A common technique for identifying missing requirements and assumptions about the software system is risk analysis. Risk can be defined as an uncertain factor whose occurrence impacts the satisfaction of high-level objectives. Risk analysis consists in a three-phase cycle: identify, assess and control. If your focus is on identifying missing domain properties, you are probably mainly interested in the first phase: identify. By identifying causes that falsify your software system, you identify (and make explicit) such missing elements.
In KAOS methodology [Lam09], risks (known as obstacle, a goal-oriented form of risk) can be identified, among other, through (a) formal regression from requirements and assumptions through domain properties - for example, a mobilized ambulance reach the incident within ten minutes, but it might be the case that it last longer, identifying missing assumption that ambulance can be lost - [Lam00] (b) the use of patterns - these patterns encodes known / standard tactics for falsifying the requirements/assumptions - [Lam00] (c) a combination of machine learning and model checking technique [Alr12]. Obstacle analysis has been successfully applied to various application domains [Lut07,Dar07].
In CORAS methodology [Lun11], risks are identified by the use of threat diagrams. Identification is driven by a systematic approach where threats and unwanted incidents are first identified, then scenarios and vulnerabilities.
Analyzing incidents and accidents might also reveal a lot of underlying, implicit, assumptions. Such analysis is strongly connected to the above risk-driven requirements engineering. In this area, I would recommend reading [Lev95] and [Lev11] .
Up to my knowledge, risk analysis is a very effective way to discover new, implicit, domain properties, missing requirements, or missing assumptions.
[Lam09] A. van Lamsweerde, Requirements Engineering: From System Goals to UML Models to Software Specifications, Wiley, January 2009.
[Lam00] A. van Lamsweerde, E. Letier, Handling Obstacles in Goal-Oriented Requirements Engineering, IEEE Transactions on Software Engineering, Special Issue on Exception Handling, Vol. 26 No. 10, October 2000, 978-1005.
[Alr12] D. Alrajeh, J. Kramer, A. van Lamsweerde, A. Russo and S. Uchitel, "Generating Obstacle Conditions for Requirements Completeness", Proc. ICSE'2012: 34th Intl. Conf. on Software Engineering, Zürich, May 2012.
[Lut07] R. Lutz, A. Patterson-Hine, S. Nelson, C.R. Frost, D. Tal and R. Harris, “Using Obstacle Analysis to Identify Contingency Requirements on an Unpiloted Aerial Vehicle”, Requirements Engineering Journal 12(1), 2007, 41-54.
[Dar07] R. Darimont and M. Lemoine, “Security Requirements for Civil Aviation with UML and Goal Orientation”, Proc. REFSQ’07 – International Working Conference on Foundations for Software Quality, Trondheim (Norway), LNCS 4542, Springer-Verlag, 2007.
[Lun11] M.S. Lund, B. Solhaug and K. Stølen, Model-Driven Risk Analysis: the CORAS approach. Springer-Verlag, 2011.
[Lev95] N.G. Leveson, Safeware: System Safety and Computers. Addison-Wesley, 1995.
[Lev11] N. G. Leveson, Engineering a safer world. MIT Press, 2011.Following
- Jürgen Münch added an answer:How to deal with stakeholders conflicts in requirements gathering?I am preparing a course on requirements analysis and was looking for some examples on stakeholders interests conflicts and how they have been resolved from real software projects and was wondering if you can share some of your experiences on this topic with us.I recommend to have a look at the Value Proposition Model-Clash spiderweb http://www.sigs.de/download/oop_08/Biffl%20Do1.4.pdf
Another interesting approach is the "Specification by Example" approach http://specificationbyexample.comFollowing
About Requirements Engineering
Requirements engineering (RE) is a systems and software engineering process which covers all of the activities involved in discovering, documenting and maintaining a set of requirements for a computer-based system.