Requirements for Development of Software Requirements

Mar, Brian W.

doi:10.1002/j.2334-5837.1994.tb01679.x

Cited by 16 publications

(7 citation statements)

References 11 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…A number of authors, including Cox et al [13], Mar [28], and Wiegers [41], advocate focusing on specification of events and exceptional scenarios. Alexander [9] underlines that ''exception cases can often outnumber normal cases and can drive project costs''.…”

Section: Related Workmentioning

confidence: 99%

“…Research shows that non-identified events (some call them ''missing logic and condition tests for error handling'' [37]) are the most common cause of changes in requirements which result in requirements volatility and creeping scope. The importance of event-completeness has been recognized by many authors (although they do not use this specific term), including Carson [11], Cox et al [13], Mar [28] and Wiegers [41]. The approach they recommend is based on identification of events performed by experts using brain storming or other ''manual'' techniques.…”

Section: Introductionmentioning

confidence: 98%

See 1 more Smart Citation

Automated events identification in use cases

Jurkiewicz

Nawrocki

2015

Information and Software Technology

View full text Add to dashboard Cite

Section: Related Workmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 98%

Automated events identification in use cases

Jurkiewicz

Nawrocki

2015

Information and Software Technology

View full text Add to dashboard Cite

“…are addressed (cf. the first characteristic for establishing requirements completeness in (Mar 1994)). Of course, the metamodel needs to contain "all categories".…”

Section: Related Workmentioning

confidence: 99%

6.1.2 Interactive Metamodel‐Compliance Checking of Requirements in a Semiformal Representation

Kaindl

Krämer

Hailing

et al. 2004

INCOSE International Symp

View full text Add to dashboard Cite

Checking requirements is highly desirable but hard to achieve in practice, where only word processors are used in most projects. While in this case reviews are more or less the only means, formal representations allow for a variety of automated checks. Unfortunately, formal representations of requirements are rarely available in real‐world projects. Semiformal representations are easier to obtain and still offer some possibilities for automated checks. Based on an object‐oriented hypertext representation, we present an implemented approach for compliance checks against a metamodel, which resembles some kind of completeness checking. In addition to allowing checks to be invoked by a human user of the tool, the checks are periodically and automatically invoked by taking into account the already existing information on the requirements. In summary, we propose an interactive approach with shared initiative between the tool and its user for compliance checking of requirements against a metamodel in a semiformal representation.

show abstract

“…A number of authors [5,7,14] have developed various numbers of attributes for requirements. The literature is not in total agreement about the meaning of these attributes.…”

Section: Characteristics Of Sound Requirementsmentioning

confidence: 99%

Developing originating requirements: defining the design decisions

Buede

1997

IEEE Trans. Aerosp. Electron. Syst.

View full text Add to dashboard Cite

A process for developing originating requirements is described.Originating requirements are the cornerstone upon which the systems engineering process is based. These requirements do not just appear, but involve a great deal of work using several important systems engineering tools: the operational concept, the external systems diagram, and the objectives hierarchy. In addition, this work provides a unified perspective on what requirements are, an appropriate taxonomy for originating requirements and an outline of the originating requirements document. This paper should serve as a discussion point for refining what may be the most important systems engineering activity. Pragmatic Principle 1 [INCOSE]Know the problem, the customer, and the consumer 1. Become the "customer/consumer advocate/surrogate" throughout the development and fielding of the solution. Begin with a validated customer (buyer) need-the problem.3. State the problem in solution-independent terms. Know the customer's (or buyer's) mission or business objectives.5. Don't assume that the original statement of the problem is necessarily the best, or even the right one.6. When confronted with the customer's need, consider what smaller objective(s) is/are key to satisfying the need, and from what larger purpose or mission the need drives; that is, find at the beginning the right level of problem to solve.7. Determine customer priorities (performance, cost, schedule, risk, etc.).8. Probe the customer for new product ideas, product problem/shortfalls, identification of problem fixes. 9. Work with the customer to identify the consumer (user) groups that will be affected by the system.

show abstract

Requirements for Development of Software Requirements

Cited by 16 publications

References 11 publications

Automated events identification in use cases

Automated events identification in use cases

6.1.2 Interactive Metamodel‐Compliance Checking of Requirements in a Semiformal Representation

Developing originating requirements: defining the design decisions

Contact Info

Product

Resources

About