Requirements Engineering - Science topic

Yes, there are several software options to draw flowcharts for computer codes. Some of these software options include Microsoft Visio, Lucidchart, and Dia.

Yes, software design is an integral part of the process of "writing" a program. While coding involves the actual implementation of the program, software design involves the planning and conceptualization of the program's structure, functionality, and user interface.

Software design differs from coding in that it focuses on the higher-level aspects of the program, such as its architecture, design patterns, and user experience, rather than the specific lines of code that make it work.

A software design is a plan or blueprint for a program that outlines its intended structure, features, and functionality. It serves as a guide for developers during the coding process and helps ensure that the final product meets the desired goals and objectives.

Hope this can provide some help:

The following links should help you.

You may read the followings for a better understanding of the requirements in context with current trends:

Some of these papers have no full-text availability, if you need, please knock me

++

These may help you.

You may read the followings for a better understanding of the requirements in context with current trends:

Some of these papers have no full-text availability, if you need, please knock me.

Plan-driven development is a conventional form of development compared to agile software development, with more importance on plan and structure in specific. Plan-driven approaches to growth concentrate on software design and performance consistency. Plan-driven approaches are related to the Capability Maturity Model (CMM) first rank framework.

The paper cited above is available at the link A Total Quality Organization Thru’ People (Part 21: Lean People, Mean People, Green People), FOUNDRY, An Indian Journal For Progressive Metal Casters, Vol. XXI, No. 2, Issue 123, pp. 41-48, May/June 2009. url= https://papers.ssrn.com/sol3/papers.cfm?abstract_id=1633896

I agree with you. Probably we need an official/standardized UML Class Diagram notation for ER modelling, but it will take time.

No such tools are used for quality requirements ...but some methods are used..

Hi Tawfeeq,

let me point you to a talk, that is probably

* not yet real research and

* not focused only the the "first phase" of software development (requirements engineering) but on the whole process as seen by Scrum, BUT

* based at least on a little survey,

* building on the Hofstede dimensions, and

* very entertaining and inspiring and thus a good starting point.

Namely:

"Scrum doesn't work in China!?" from Bas Vodde presented in 2010.

There is a short note about it in Bas Vodde's blog (https://blog.odd-e.com/basvodde/2010/06/scrum-and-culture.html) linking to a video of his presentation (http://www.infoq.com/cn/presentations/bas_scrum_china) and the slides are available (https://www.odd-e.com/material/2010/scrum_shanghai/culture.pdf) as well.

For your own research you probably need to add more methodology. My first stop for methodology in software engineering research is Steve Easterbrook, Janice Singer, Margaret-Anne Storey, Daniela Damian: "Selecting Empirical Methods for Software Engineering Research" but you might need to go beyond what they discuss.

Interesting topic! Besides, there seems to be a global software engineering culture be developing that might in turn influence the national cultures.

Good luck, dsp

yes i am

You can also use S.P.L.O.T tool. It is online tool and very useful .

Hi Felix,

thanks for your answer.

The purpose and application of video in RE has several facets, as you already mentioned. All the points you stated are possible applications of video.

This survey has the intent to understand the current attitudes, advantages, disadvanteges, potentials and concerns towards video in general.

We want to understand how video as a medium for presenting or obtaining information is perceived by different the participants.  For us, it is important to understand at first whether video is currently used or not and for which purpose it is used or should be used. And therefore, we want to focus on the the perspective of the survey participants and not our intuition.

I hope this information is helpful and that you will finish the survey.

Cheers

Olli

this depend on publishers,Usually, they take 2 - 3 months to review research articles,some time less

Dear Researcher

My expertise area includes requirement engineering and Bigdata

Dear Peter Stoyanov Sabev sir,

Thank you very much for replying. This information of yours is really helpful.

There is not much evidence on this topic. Only anecdotal. You might check out the literature on Fagan inspections, as these studies usually measure defect densities.

First, be careful to build on pre-existing domain knowledge and build a vocabulary together with each of your customer segments — in their own language. The vocabulary may serve you well in communicating.

Then, listen to your customers, socialise prototypes with them, and structure the resulting understanding using use cases. Then elicit their feedback on the result and iterate because, in spite of best intents, we usually mis something.

There is no formulaic approach in a complex domain.

Hi Stephan, I'm with Maya and her recommendations and basically I'm with Andre too, but I would like to extend his approach by adding these thoughts:

A classic: "James O. Coplien. Borland Software Craftsmanship: A New Look at Process, Quality and Productivity. In Proceedings of the Fifth Borland International Conference, Orlando, Florida, June 1994."  https://sites.google.com/a/gertrudandcope.com/info/Publications/Patterns/Process/QPW

You may look at w6h.org

What best satisfies user needs?

Two steps:

1. Define "user needs", by which I mean quantify the requirements, each with either benefit, cost, priority or any set of these

2. Define "best": make a decision criteria to determine how low priority the last implemented unit must have, how many "penalties" can be allowed, or how many benefits must be received to pass for release. Or a combination of these.

Both of these should be done in communication with the one who pays and the one who is to be the user.

I'd like to know what you mean by "quality" and "after compiling" before fully answering. If you mean conformance to requirements, the only way you can improve a compiled version of the software is to wrap it in other software that disables some of its functionality (e.g., by limiting ranges on parameter values, controlling the sequence in which APIs are invoked, or excising some APIs altogether). This doesn't change the requirements conformance of the software component itself but may improve the quality of the system in which it is embedded. The extreme case would be to take a bad module and to put it together with another module that completely replaces its functionality. Though the software is part of the deliverable it is never called, its function having been taken over by the surrogate.

If you embed that software into software that takes none of these approaches, you can only *lower* the overall quality. Think of a hardware analogy: if a board has just one badly designed integrated circuit that has a certain number of failures in a trillion (FITs), adding more chips will only cause their FIT values to lower the end-to-end reliability — unless a high-reliability component is used to hide/wrap the faults of the one under consideration.

Conjecture:  Customers and developers must have “sufficiently equivalent” rich ontologies in a domain of discourse (e.g. flight control) to have meaningful discussions about quality attribute goals (e.g. safety goals, ease of use goals, understandability goals).

Conjecture:  If the domain is familiar and the parties are experienced, they are likely to share an ontology.

Questions:  What happens when the domain is unfamiliar to both parties (e.g. to determine compliance of prescription drug ads with FDA regulations)?  What happens when one or both of the parties are inexperienced?  Is meaningful consensus on quality goals possible in these scenarios and under what conditions?

Barry Boehm is working to develop an ontology for quality attributes.  Is a single ontology likely to be useful across the spectrum of software applications and organizations or will organization-tailored and project-tailored quality ontologies be more useful?  Will something else be more useful?

Hope this helps.

It is may be easier to script the requirements as a configuration file and load the variables to workspace and then proceed to simulink.

@ Ljubomir Jacić Thanks for your valuable data and advice

there are 2 reference papers discussed about it:

Dear 

Mehrpooya Ahmadalinejad

for more information about this subject please study "P-CMM" : People Capability Maturity Model

There are many formal systems for tracking requirements etc, but much of the software is proprietary.

I believe the following book answers some of your questions from an industrial / applications perspective ...

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.

That's a really interesting research question! I'll try to rephrase it the way I understood it.

Is it possible for a machine to infer implicit requirements based on a set of explicit requirements?

In my opinion this is dealing a lot with knowledge representation and engineering, and how to discover tacit knowledge from domain experts.

To lay the foundation for discussion here is an example that I am currently working on for a current project.

Inquiry vs. Report (Definitions (http://www.thefreedictionary.com)

Inquiry (noun) - a request for information; a question

Inquire (verb) - to seek information by asking a question

Report (noun) - an account presented usually in detail

Report (verb) - to write or provide an account or summation of for publication or broadcast

I frequently reviewing existing documentation to identify the business concepts and terms, which then leads to defining these business terms as analysis classes (e.g. product). In the terms of the above definitions I would consider the capability to view/update the details of a product as an Inquiry, while viewing a list of products as a report.

The distinction I am considering is that an inquiry feature may be expected to be extended with CRUD operations to manage business object's data, while a report feature would not.

Furthur analysis of a user's needs may identify the requirement that they be allowed to edit multiple business objects and multiple attributes within one UI, however the concept of an Inquiry would remain the same.

Obviously there are many similarities between the two concepts and it might be useful to model Inquiry as a specialized for of a report. E.g., they both have selection criteria, execution options, and delivery/presention options. However the fundemental concept difference would be the separating data entity CRUD operations.

The difference between these two concepts would apply ONLY within the analysis effort as the design choices would NOT be constrained by these distinctions.

Furthur the ultimate requirements statements derived from the model (using statement templates) would NOT reference these concepts. This is to support the goal of constraining the terms used within the requirement statements to a structured business vocabulary.

Let me know your thoughts, concerns, or recommendations,

thanks,

David

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?

I've been using a cost consequence analysis as a quick, preliminary method in costing software use in healthcare and its potential impact.

You may want to look at our CSES portfolio. It can be applied to your question with respect to risk management. One of our papers reference Barry Boehm's work in this area. http://academic.research.microsoft.com/Paper/4813650.aspx

Our work:

DOI: 10.1109/HICSS.2009.308

DOI: 10.1109/CICYBS.2009.4925092

All the best.

Bob

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!

TCGEN is used to for specification based testing from Unified Modeling Language statecharts. There are other techniques to do it, but I l found this one is most effective of all.

If you don't have any requirement then it is impossible to do a cost estimate . . simply because if you do not have a requirement then you don't know what you need and you can't make a cost estimate if you don't know what you need.

But you have at least one requirement: you need Shop Management Software

You can use two approaches:

1. Analogy. If you have cost estimates on different software applications you can order them by cost and try to position your Shop Management Software to get a rough order of magnitude.

2. Construct high-level requirements. What is my Shop Management Software supposed to do. I know of two FPA-based techniques to translate those high-level requirements to a function-point size, which can be translated to a cost estimate. The first is "FPA in Early Stages" from NESMA www.nesma.nl/section/books/ and the other is the Early & Quick FP approach from DPO www.dpo.it/sito%20inglese/eqfp/index.htm

I suggest to take a look in the classification of NFR that makes Ian Sommerville, it is very illustrative and you can find it in his Software Enginnering text book.

It is important to have a glossary. However, in these days of agile, such artifacts are not valued by the client unfortunately.

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 ?

I found a new citation:

"The final element in a data processing problem is the set of operational requirements of the system. These are the requirements that are not related to the logic of the problem [...]"

J. W. Young Jr. and H. K. Kent, “Abstract formulation of data processing problems,” Journal of Industrial Engineering, vol. 9, no. 6, pp. 471–479, November-December 1958.

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.

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.

Tracking the tenuous links between stakeholders could go on for ever and you need to draw boundaries as to whom you should consider. This depends very much on the nature of the systems being designed, but largely requires plain common sense. The first things to find out is who are your users according to the context of the system (for Example designing generic software is difficult because of many different users with different purposes and characteristics.) Instead of thinking of a generic user with generic skills and goals is better to think on several specific users. Second you have to consider that "you" and your own interests and abilities can differ from other users. Third step is talking to your "possible" stakeholders (participatory design): structured interviews, open-ended discussions, or bringing the stakeholders into the design process. I used the participatory design for my last project and the result were impressive. A system must be not only useful and usable, but also USED. Forth step is to "watch" your stakeholders and "hear" what they say. This may involve sitting and taking notes how they use a system like yours. You can use a video camera or tape recorder. Their explanation have to match what they really do. The last step is called: use your imagination. Even if you cannot involve every actual stakeholders you can at least try to imagine their experiences. One method that has been quite successful in helping design teams produce user-focused designs is the "persona"(a rich picture of an imaginary person who represents your core user group ).

References: Human-Computer Interaction; Alan Dix, Janet Finlay, Gregory D. Abowd, Russell Beale

I suggest software product line specification and verification -- but there are many others.

Will it be possible for you to share the findings.

My favorite tool for capturing EA modeling is Essential Architect Manager. View this tool at http://www.enterprise-architecture.org/ See rmtoo which is an open source requirements management tool at http://www.flonatel.de/projekte/rmtoo/. The last update was in 2012 but the source code is available which means you could potentially make updates yourself. Trak an enhanced wiki and issue tracking system for software development projects which can be viewed at http://trac.edgewall.org/.Another tool is Archimate Modeling at http://archi.cetis.ac.uk/ however that is more UML. I hope this is off assistance.

@Joseph Thanks a lot for your replies

The role of usability evaluation as it relates to Human-computer interaction cannot be underestimated.The Software development process consists of an interconnected set of essential ingredients such as the analysis, requirement specification, design, implementation, testing, and maintenance phases. Interestingly, usability evaluation play a vital role in software testing. However, when it has to do with Human-computer interaction, the interaction between users of the software being tested and the functionalities of the software's Graphical user interface will help provide meaningful feedback that can be instrumental at improving the overall quality of such software.

Event-B is a rigorous formal method for system specification. Rodin is an Eclipse-based IDE that provides tool support for Event-B. One Rodin plug-in is UML-B which, as its name suggests, combines UML and B. You may want to google Colin Snook (EECS/Univ Southampton), which is the main designer and maintainer of UML-B, I believe. He has also authored several papers on this approach.

The selfish answer: URML, see my profile.

But, of course I should refer to FODA by Kang et al., a revision of FODA is FORM . You should also look into the book by Krysztof Czarnecki, Ulrich Eisenecker: "Generative Programming: Methods, Tools, and Applications: Methods, Techniques and Applications".

A review paper I recently found is

V. Vranić, “Reconciling Feature Modeling: A Feature Modeling Metamodel,” in Object-Oriented and Internet-Based Technologies, vol. 3263, M. Weske and P. Liggesmeyer, Eds. Springer Berlin / Heidelberg, 2004, pp. 245–255.

A relationship of requirements to features, that relates Jacksons work to features:

A. Classen, P. Heymans, and P.-Y. Schobbens, “What’s in a Feature: A Requirements Engineering Perspective,” in Fundamental Approaches to Software Engineering, vol. 4961, J. Fiadeiro and P. Inverardi, Eds. Springer Berlin / Heidelberg, 2008, pp. 16–30.

The requirement model is based on the requirements elicitation suggested by the users, customers and other stakeholders. However, a specification model starts and is based on the requirement model and is more formal than in the sense that it uses several techniques for modeling in order to more understand the requirements.

I searched this method only which measures the quantitative cost of defects, i am searching more, please help me...

A paper that is cited very often and gives a good overview is the following:

L. Chung and J. C. S. do Prado Leite, “On Non-Functional Requirements in Software Engineering,” in Conceptual Modeling: Foundations and Applications, vol. 5600, A. Borgida, V. Chaudhri, P. Giorgini, and E. Yu, Eds. Springer Berlin / Heidelberg, 2009, pp. 363–379.

The URML (part of my work) supports modeling non-functional requirements.

The problems I encounter are not solved by computer tools as they come from the people involved in the process.

Domain Familiarity: knowledge of product domain and its related jargon

Interpretation: One sentence, two meanings

Exuberance: Inability to focus and hence extract essence of product

Scope-determination: the ability or otherwise to determine the products boundaries

resolution-determination: the ability or otherwise to control the detail required

Model Complexity: Text or anything else that attempts to define the requirements

Commonality: the background of those involved in the requirements determination

Emmotives: Sales-pitch and subterfuge

There are 8 potential classes for you. There may be others