Ross D, Schoman A (1977) Structured analysis for requirements definition. IEEE Trans Softw Eng (Special issue on requirements analysis) 3(1):6--15  Home/Search   Document Not in Database   Summary   Related Articles   Check

....approaches to software requirements espouse some particular paradigm that is meant to capture all relevent aspects of a proposed software system. Usually this paradigm is embodied in a single requirements language, such the Software Requirements Engineering Methodology s (SREM) RSL [2] 3] SADT [4] [5] CORE diagrams [6] RML [7] entitydataflow diagrams [8] or statecharts [9] While these languages have been carefully designed to suit the purposes of requirements development, two obstacles restrict their usefulness: 1) each language s limitations make it inconvenient or impossible to ....

D.T. Ross and J. Kenneth E. Schoman, Structured Analysis for Requirements Definition, IEEE Trans. Softw. Eng. SE-3 (1), 6-15 (1977).

....tools which we have developed. Finally, we reflect on the effectiveness of this method and its possible development. 2. Viewpoints The notion of viewpoints as a means of organising and structuring the requirements engineering activity is now well known. Viewpoints are implicitly present in SADT [3] and were first made explicit in the CORE method [4] Since then there have been various other viewpoint based approaches and proposals [5,6,7,8] We have summarised these methods and described our own work on viewpoints for interactive system design elsewhere [9,10] VORD defines two classes of ....

Schoman, K. and Ross, D.T., "Structured Analysis for Requirements Definition." IEEE Trans. on Software Engineering. SE-3(1), pp.6-15, 1977.

....a system will sup port. Goal based approaches focus on why systems are constructed providing the motivation and rationale to justify software requirements. The notion of focusing on the why is not new, although organizing requirements around goals is (e.g. Context analysis, introduced in [9], determines the reasons why a system is to be created and the purpose of the system according to different viewpoints) A viewpoint captures a particular responsibility performed by a participmt at a particular stage in the development process. The ability to represent viewpoints and distinguish ....

Ross, D.'. and K.l,. Sc},oman Jr., "Structured Analysis for Requirements Definition," IEEE Transactions on Software Engineering, 3(1), pp. 6-15, January 1977.

....META system. Systems descriptions can then be formulated in that particular PSL. This approach has been tested on structured methodologies [11, 16, 40] and the results are encouraging. The main user interface, however, is still formal. 3. 2 STRUCTURED ANALYSIS AND DESIGN TECHNIQUE (SADT) SADT [12, 30] has been developed by SofTech Inc. A specification is made up of a hierarchy of SADT diagrams, each of which is a network of boxes representing activities, as shown in Figure 3. The arrows at the four sides of each box represent Input, Output, Control and Mechanism for the activity involved. The ....

D.T. Ross and K.E. Schoman, "Structured analysis for requirements definition", in Classics in Software Engineering, E. Yourdon (ed.), Yourdon Press Computing Series, Prentice Hall, Englewood Cliffs, New Jersey, pp. 365-385 (1979).

....organised in order to obtain a consistent set of scenarios that represents the application domain. During or after these activities, the scenarios are verified and validated with the clients users to detect discrepancies, errors and omissions (DEO) To describe the process, we will use an SADT [38] model (Fig. 7) where the following activities are mentioned: 1. DERIVE; 2. DESCRIBE; 3. ORGANISE; 4. VERIFY; 5. VALIDATE. Although the process of scenario construction depicted in Fig. 7 shows a main stream composed of three tasks: DERIVE, DESCRIBE and ORGANISE, these activities are not ....

Ross D, Schoman A. Structured analysis for requirements definition. IEEE Trans Software Eng (special issue on requirements analysis) 1977;3(1):6--15

....paper, requirements definition must say why a system is needed, based on current or foreseen conditions , which may be internal operations or an external market. It must say what system features will serve and satisfy this context. And it must say how the system is to be constructed [Ros77] Many informal system development methodologies from the good old times included some form of goal based analysis, called context analysiis [Ros77] definition study [Hic74] participative analysis [Mun81] and so forth. Typically, the current system under consideration is analyzed in its ....

....an external market. It must say what system features will serve and satisfy this context. And it must say how the system is to be constructed [Ros77] Many informal system development methodologies from the good old times included some form of goal based analysis, called context analysiis [Ros77] definition study [Hic74] participative analysis [Mun81] and so forth. Typically, the current system under consideration is analyzed in its organizational, operational and technical setting; problems are pointed out and opportunities are identified; highlevel goals are then identified and ....

[Article contains additional citation context not shown here]

D.T Ross and K.E. Schoman, "Structured Analysis for Requirements Definition", IEEE Transactions on Software Engineering, Vol. 3, No. 1, 1977, 6-15.

....of 70 s, structured programming[15] and the idea of modularization based on information hiding[43] were proposed. After the time came in the latter of 70 s, many interests were on the methods for constructing specifications. The family of structured methods such as ISDOS[62] SREM[4] and SADT[48] were developed at that time, and they supported the construction of specification documents only, especially for business systems. In 80 s, the methods haveevolved into ones so that they could support the whole of software development processes, i.e. the phases from requirements analysis to ....

D.T. Ross and K.E. Schoman Jr. Structured Analysis for Requirement Definition. IEEE Trans. on Software Engineering,Vol. 3, No. 1, pp. 6--15, 1977.

....activities. Entities flow from activity to activity. Further conditions and properties, such as pre conditions and temporal or other constraints, can be attached to activity and entity descriptions. The features of the Workflow model are based on RML [Greenspan84] which is based in turn on SADT [Ross77] A WF model can be analyzed for completeness and consistency of input output and other properties. Violations of temporal precedence and other constraints can also be detected. This level of modelling presents a non intentional description of a work process it can answer what questions, ....

.... LEGEND non func. goal func. alternative contribution pos. contribution neg. contribution sup (enough) sub (partial) AND OR Figure 4: Non Functional Rationales Model (NFR) information systems as integral, embedded elements. Figure 5 shows, in the format of an SADT activity diagram [Ross77] how the four models are inter related. A requirements engineering process may be initiated by some process design objectives, such as improving service or reducing costs. These non functional design goals would lead to considerations of functional alternatives (e.g. expert system vs. human ....

D. T. Ross and K. E. Shoman, Structured Analysis for Requirements Definition, IEEE Trans. Soft. Eng., Vol. SE-3, No. 1, Jan. 1977.

....(generally associated with requirements or object oriented analysis) and generaltechnology oriented representations (generally associated with object oriented design) see Figure 8. Although the recursive hierarchical nature of why whathow relationships has been well known for some time [Ross Schoman, 1977], within the context of Figure 8 the quadrants can be considered to relatively address the questions of why where; what; how; and do. Figure 8 Figure 8. ISDM Product Model Relationships The people technology and general specific distinctions in Figure 8 are not entirely orthogonal, however they ....

. D.T. Ross and K.E. Schoman, "Structured Analysis for Requirements Definition," IEEE Trans. SW Engr., January 1977, pp. 41-48.

....a system will support. Goal based approaches focus on why systems are constructed providing the motivation and rationale to justify software requirements. The notion of focusing on the why is not new, although organizing requirements around goals is (e.g. Context analysis, introduced in [9], determines the reasons why a system is to be created and the purpose of the system according to different viewpoints) A viewpoint captures a particular responsibility performed by a participant at a particular stage in the development process. The ability to represent viewpoints and distinguish ....

Ross, D.T. and K.E. Schoman Jr., "Structured Analysis for Requirements Definition," IEEE Transactions on Software Engineering, 3(1), pp. 6-15, January 1977.

....experiences with domain modeling have been gained with a commercial implementation of an early Telos version [29] For an example, we continue with the definition of a subset of the notions of RML [25] begun in section 3. As indicated earlier, RML s basic structures are loosely based on SADT [49]; this was motivated in part by the idea of using SADT as a graphical road map which sketches the requirements model before filling in the more formal semantic details. RML provides the three basic mechanisms of Activities, Entities, and Assertions. Since the latter are already available in the ....

Ross, D., and Schoman, K. Structured Analysis for Requirements Definition. IEEE Transactions on Software Engineering (1977), 49--60.

....when the application system being put into use. But we can make the requirement specification as close as possible with the needs of the customers and let the unmatched parts be smaller and smaller. A variety of techniques to enhance requirements have been developed during the past years: SADT[7, 6], objectoriented analysis[3, 13] and rapid prototyping[14, 23] ect. Recently because of the acknowledge that multiple participants are necessarily involved in system development, multiple viewed approaches have been studied[1, 22, # This work is partly supported by the Royal Society of the UK, ....

D.T.Ross and J.Kenneth E.Schoman. Structured analysis for requirements definition. IEEE Transactions on Software Engineering, 3(1):6--15, 1977.

....the importance of Enterprise Modeling as providing a common understanding of the enterprise and its interactions which can then be used to rationalize and improve these interactions. 2.1.3 Principles of Enterprise Modeling As with any technique, it is made more useful with structure. Ross (Ross and Schoman 1977) lists the four main requirements of any modeling technique. These include: a distinct purpose for the model, the range of the model which is commonly referred to as the boundaries of the model, the viewpoint of the model, and the detailing level of the model. Vernadat 10 (Vernadat 1996) extends ....

Ross, D. T. and K. E. Schoman (1977). "Structured Analysis for Requirements Definition." IEEE Transactions on Software Engineering SE-3(1): 6-15.

....of the needs that a system is to fulfill. It must say why a system is needed, based on current or foreseen conditions, which may be internal operations or an external market. It must say what system features will serve and satisfy this context. And it must say how the system is to be constructed [Ros77b]. In other words, requirements engineering must address the contextual goals why a software is needed, the functionalities the software has to accomplish to achieve those goals, and the constraints restricting how the software accomplishing those functions is to be designed and implemented. Such ....

....and structuring mechanisms supported essentially emerged by abstraction from the programming field [Myl99] the same way as structured analysis came out by abstraction from structured programming techniques. In particular, the why concerns in the early stages of requirements engineering practice [Hic74, Ros77b, Mun81, Ber91] are not addressed. The aim of this section is to illustrate the benefits of looking the other way round for the purpose of requirements elicitation, specification, and analysis that is, to start thinking about objectives as they arise in preliminary material provided, use goal ....

D.T. Ross and K.E. Schoman, "Structured Analysis for Requirements Definition", IEEE Transactions on Software Engineering, Vol. 3, No. 1, 1977, 6-15.

....to precise specifications of software behavior, and to their evolution over time and across software families. This general definition, borrowed from [Zav97a] stresses the leading part played by goals during requirements elaboration. Goals drive the elaboration of requirements to support them [Ros77, Dar91, Rub92]; they provide a completeness criterion for the requirements specification the specification is complete if all stated goals are met by the specification [Yue87] they provide a rationale for requirements a requirement exists because of some underlying goal which provides a base for it [Dar91, ....

D.T. Ross and K.E. Schoman, "Structured Analysis for Requirements Definition", IEEE Transactions on Software Engineering, Vol. 3, No. 1, 1977, 6-15.

....analysis [Rumbaugh et al. 1991; Jacobson et al. 1993; Booch, 1994] incorporate an implicit notion of viewpoints. These methods suggest that a number of different system models should be developed, each of which can be thought of as a different viewpoint on the system. SADT [Ross, 1977; Schoman and Ross, 1977] Viewpoints paper, Annals of SE, March 1996 Page 10 goes further in that it suggests that analysis should be undertaken from different viewpoints but it does not include viewpoints as explicit entities in the method. Rather, viewpoints are seen as sources or sinks for data in a data processing ....

Schoman, K. and Ross, D. T. 1977. Structured Analysis for Requirements Definition.

....into formal ones, and the translation of high level specifications into low level ones. Consequently, the team researchers decided to concentrate on the second problem which led to the knowledge based specification assistant (KBSA [24] Two other early projects were PSL PSA [33] and SADT [29], both supporting a dataflow based methodology. PSL PSA consists of a structured language (PSL) and an analyzer (PSA) SADT provides a graphical tool and a design methodology. Several enhancements to the dataflow oriented methodology were subsequently proposed (e.g. SASS [17] DFD [38] ....

Ross, D. and K. Schoman, "Structured Analysis for Requirements Definition," IEEE Transactions on Software Engineering 3,1 (Jan 1977), pp 6-15.

....and weaknesses of using IDEF0 in this environment. HISTORY AND BACKGROUND OF IDEF0 IDEF0 has its beginning with Structured Analysis and Design (SADT) Softech, Inc. developed SADT in the mid 1970s in an effort to overcome some of the shortcomings of the modeling and analysis methods of that time [8]. In the late 1970s, the Air Force selected SADT as the language to support its Integrated Computer Aided Manufacturing (ICAM) initiative [4] It was from this effort that IDEF0 was developed and brought into wide use, especially within the aerospace industry. Since that time much has been ....

Ross, D.T. and K.E. Schoman. "Structured Analysis for Requirements Definition". IEEE Transactions on Software Engineering. SE-3, 6-15 (1977).

.... presented in this paper provides an overall framework and structure for interaction with stakeholders, and relies on a more active role of the stakeholders involved to achieve the consensus that leads to completeness [1] The notion of viewpoint was introduced as early as 1977 by Ross and Schoman [10]. They defined viewpoint as being a particular aspect of a product or product development, such as performance, rather than as being a perspective held by a particular stakeholder in the product. Interestingly, they described an economic viewpoint , which in essence is one of the two components ....

D.T. Ross and K.E. Schoman. Structured Analysis for Requirements Definition. IEEE Transactions on Software Engineering, 3(1):6--15, January 1977.

....the activities to be performed, and guiding the execution of these activities and the use of the products. Examples include the Waterfall model [Roy70] Spiral model [Boe88] Jackson System Development [Jac83, Cam86] Booch Object Oriented Design [Boo83, Boo86] Structured Analysis and Modeling [RJ77, GS86, BBD77, EFRV86] and Structured Design [Mye78, Ber78] Several problems prevent current software methodologies from being fully and generally successful. The specifications of software processes and products are too often semi formal or informal (if specified at all) the processes rely on ....

Douglas T. Ross and Kenneth E. Schoman Jr. Structured analysis for requirements definition. IEEE Transactions on Software Engineering, SE-3(1):6--15, January 1977.

....email: grosz cse.uta.edu These two steps correspond to the abstraction levels defined in the ANSI X3 SPARC report [1] namely the conceptual and the internal level. The design process is a creative process primarily supported by the designer. Design methodologies whether functional (i.e. SADT [2]) or systemic (i.e. REMORA [3] are limited to define a sequential list of tasks. The different tasks are not formally defined, they are organized in a linear manner, this does not reflect the practical reality of design. Therefore, it is necessary to improve our understanding of the ....

: D.T. Ross, K.E. Schoman: "Structured Analysis for Requirements Definition", IEEE Transactions on Software Engineering, Vol. 3, N°1, January 1977.

....4.2. Due to their research oriented nature, it should be expected that technology provision will be prototype oriented with evolutionary introduction of new features. ffl Process requirement analysis: Generally, we believe that conventional methods for analysing information systems (like SADT[Ros77] semantic modeling, object oriented analysis) can be used for certain aspects. However, our current knowledge of especially the fine grained process aspects is 5 Software artifacts have longer life time and are more stable than their models [Est92] very low, and we will need to rely on ....

D. T. Ross and K. E. Schuman. Structured Analysis for Requirements Definition. IEEE Trans. on Software Engineering, SE-3(1), pages 16--34. January 1977.

No context found.

Ross D, Schoman A (1977) Structured analysis for requirements definition. IEEE Trans Softw Eng (Special issue on requirements analysis) 3(1):6--15

No context found.

D. T. Ross and K. E. Schuman. Structured Analysis for Requirements Definition. IEEE Trans. on Software Engineering, SE-3(1):16--34, January 1977.

No context found.

Schoman, K., Ross, D. T.: "Structured analysis for requirements definition," IEEE Transactions on Software Engineering, 3(1), pp. 6-15, 1977.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC