Software Requirements Engineering Methodology

Abstract

The reader who wishes to learn how to write software requirements using the SREM techniques should first study the language and support software capabilities described in the REVS Users Manual [1]. However, a general understanding can be obtained from this manual alone. To facilitate this, a brief overview of RSL and REVS is provided here. i.3.1 The Requirements Statement Language (RSL) RSL is an extensible language which means that certain primitive concepts are built in and the user can use these to define more complex language concepts. The primitives are elements, attributes, relationships, and structures. From these, we have defined a nucleus of concepts which to date have proven sufficient. Future users of the language can add to these by means of the extension features as required. These concepts are introduced as they are used in this manual, and are presented in full in Appendix A. The Requirements Statement Language is a user-oriented mechanism for specifying requirements. It is oriented heavily toward colloquial English, and uses nouns for elements and attributes and transitive verbs for relationships; a complementary relationship uses the passive form of the verb. Both syntax and semantics echo English usage, so that many simple RSL sentences may be read as English with the same meaning. However, the precision of RSL, enforced through machine translation, is not typical of colloquial speech; as a result, most complex RSL sentences are a somewhat stylized form of English. 1.3.2 The Requirements Engineering and Validation System (REVS) REVS is an integrated set of tools used to support the definition, analysis, simulation, and documentation of software requirements. A key concept of REVS is that all requirements are translated into a central data base called the Abstract System Semantic Model (ASSM). The RSL statements themselves are not stored in the ASSM. Instead, they are translated into representations of the information content of the requirements statements. This provides an efficient and flexible means of maintaining a large software specification in a relatively small computer data base.

TORUS: Tracing Complex Requirements for Large Cyber-Physical Systems

“…Key to Alford and Lawson's recommendations were the use of formal mathematical methods to support requirements engineering processes (Alford & Lawson, 1979, page xiv). Hamilton and Zeldin's earlier work on design and verification of spacecraft guidance systems emphasizes the same need by relying on formal mathematics for verification.…”

“…If TORUS can scale comfortably to manage a model with 1,000,000 requirements in it such as the one outlined by Alford and Lawson (1979), then the methodology shows great promise.…”

“…The earliest references to software requirements engineering in a distributed, embedded system's environment is Alford and Lawson's work at TRW, a U.S. Department of Defense provider in the early 1970's (Alford & Lawson, 1979). They echo Hamilton and Zeldin's reflections on the difficulties encountered in the design and verification of software used on the Apollo program during the 1960's (Hamilton & Zeldin, 1976).…”

Challenges of SMR Licensing Practices

“…The inspections, tests, analyses and acceptance criteria could be handled in SMR licensing within the licensing steps in the Requirements Management (RM) process V-curve [20]. Requirements Management is part of Systems Engineering, which has been developed in the software modeling field and used widely, e.g.…”

Cost Estimation in Agile Software Development Projects

“…Alford and Lawson (1979) pointedly remark that "in nearly every software project that fails to meet performance and cost goals, requirements inadequacies play a major and expensive role in project failure". As yet, the issue of cost estimation in agile software development projects has received very little attention in the academic literature, the only previous empirical studies that we discovered in our literature search being those of Cao (2008), who conducted an in-depth longitudinal study on an agile project in which estimates were compared versus actuals, and Ramesh et al (2007), who investigated agile requirements engineering practices within 16 US software development organizations.…”