Diagram Oriented Requirement Specification and the DorsGen Tool

Transcription

1 The Open University of Israel Department of Mathematics and Computer Science Diagram Oriented Requirement Specification and the DorsGen Tool This thesis submitted as partial fulfillment of the requirements Towards an M.Sc. degree in Computer Science The Open University of Israel Computer Science Division By Ronen Halabi Prepared under the supervision of Dr. Shmuel Tyszberowicz November 2006

2 Abstract SRS is a document, which is used as a means of communication between all the stakeholders for a system under development (SUD). The requirements might change even after the acceptance of the SRS by all parties, and those changes must be tightly controlled. A clear and correct SRS document assists the maintenance and enhancement of the document, helps to have traceability between the requirements, the design, and the code, and helps to keep the SRS document and the code updated. Unfortunately, writing an SRS document is not easy, and many times it is incorrect, inconsistent, or ambiguous. A CASE tool is useful to help in writing a correct SRS. Such a tool should provide facilities for: Creating the document, checking its correctness, easily changing its content etc. This work describes DorsGen (Diagram Oriented Requirement Specification Generator), It is an easy-to-use software tool for automatically generating SRS documents and diagrams, such as Context Diagram, Use Case Diagram, Data Dictionary, DFD, Class Diagram, etc. 2

3 TABLE OF CONTENTS 1. Introduction What is a software requirement specification Functional requirements Non-functional requirements SRS characteristics SRS standards How to specify requirements Context diagram Use case diagram Data dictionary DFD diagram Class diagram State Chart diagram Sequence diagram Aspect oriented approach Crosscutting concerns What is an aspect Aspect-oriented programming AspectJ Aspect-oriented design SRS tools Why are tools needed Requirements for an SRS tool SRS tools Smart draw RDD Analyst Pro AxiomSys EasyRM

4 4.3.6 IRqA RequisitePro DOORS DorsGen Features supported by DorsGen DorsGen advantages Model for writing requirements using DorsGen Conceptual Overview Requirements Capturing Requirements Analysis Requirements Verification Summary and future work Managing requirements with attributes Requirements traceability - ensuring quality and managing change Requirements reporting - easing management reviews Identify crosscutting Aspect oriented requirements in the DorsGen References APPENDIX 1: IEEE 830 standard APPENDIX 2: MIL-STD-498 standard APPENDIX 3: DFD verification rules APPENDIX 4: BNF rules APPENDIX 5: DorsGen example of tracing aspect

5 APPENDIX 6: Aspect diagram example APPENDIX 7: Use case template APPENDIX 8: DorGen Schemas APPENDIX 9: Generated document example APPENDIX 10: DorsGen user manual תקציר אוניברסיטה הפתוחה FIGURES Figure 1: Billing system crosscutting example...40 Figure 2: Modular units and aspect...41 Figure 3: The DorsGen tool...68 Figure 4: IEEE-830 schema...68 Figure 5: Defining requirements window...69 Figure 6: Document result...70 Figure 7: Use-case definition...73 Figure 8: system object diagram...73 Figure 9: Abstract diagram..74 Figure 10: One of the extended diagrams...74 Figure 11: Context diagram...75 Figure 12: DFD0 diagram...75 Figure 13: Use-case document result...76 Figure 14: Default types...77 Figure 15: Data dictionary table

6 Figure 16: Data store table...78 Figure 17:DFD diagram...79 Figure 18:class and aspect diagram...80 Figure 19: Verification results...81 Figure 20: Defining the new schema structure...83 Figure 21: One of the paragraph types...83 Figure 22: The new standard graphics result...84 Figure 23: Writing Requirement model...91 Figure 24: Requirements Capturing...92 Figure 25:Requirements Analysis...94 Figure 26:Requirements Verification...95 Figure 27: Bounded-buffer aspect diagram Figure 28: DorsGen main window Figure 29: IEEE-830 Standard button in the toolbar Figure 30 :IEEE-830 uploaded standard Figure 31 :Inserting data window Figure 32: Context diagram button Figure 33: Context diagram window Figure 34: Adding new actor Figure 35: Adding actor result Figure 36: Context diagram paragraph Figure 37: Data dictionary button Figure 38: Data dictionary window Figure 39: Default types Figure 40: Data type table Figure 41: Data dictionary table Figure 42: Data store table Figure 43: DFD button Figure 44: DFD0 window Figure 45: Adding new process in DFD Figure 46: Adding new data store Figure 47: Insert link Figure 48: DFD adding link result Figure 49: Requirement paragraph Figure 50: Generated DFD result Figure 51: Creating DFD Figure 52: DFDn in the requirement paragraph Figure 53: DFD verify button Figure 54: DFD verification results

7 Figure 55: Use case button Figure 56: Abstract diagram Figure 57: Extend diagram Figure 58: Defining objects Figure 59: Objects result Figure 60: Class diagram button Figure 61: Class diagram window Figure 62: Adding new class Figure 63: Adding relation between classes Figure 64: Class diagram verify Button Figure 65: Class diagram verification result Figure 66: Compilation button Figure 67: Compilation result Figure 68: View button Figure 69: Document view result Figure 70: Save button Figure 71: Directory navigation Figure 72: DorsGen generation output Figure 73: open button Figure 74: Reopen result Figure 75: Wizard button Figure 76: Wizard window Figure 77: Defining the new schema structure TABLES Table 1: Users of requirements documents...11 Table 2 Comparison of Related tools...66 Table 3 Comparison between DorsGen and Related tools

8 1. Introduction This thesis presents a model of writing Software Requirements Specification, along with an implementation of that model, in the form of an interactive tool called DorsGen (Diagram Oriented Requirement Specification Generator), both designed to provide a synergistic approach to the software requirements generation process. Early experience in building software systems showed that existing methodologies were very wrong. Major projects were, years late, they cost much more than originally predicted, were unreliable, difficult to maintain and performed inefficiently. The inadvertent delays and significant budget overruns caused software costs to rise, while hardware costs were plummeting. New techniques and methods were needed to control the complexities inherent in large software systems. After more than 30 years of development, the software industry has made enormous progress in developing reliable software, within budgetary and schedule constraints. Developers now have a better understanding of various processes involved in software development, and have modeled these processes in the form of software development lifecycles, lending much-needed structure to the overall development process. Nevertheless, many large software projects are still late and over-budget, moreover, software that is delivered often does not meet the real needs of the customer. The importance of a well-defined, effective set of requirements engineering activities is constantly being reinforced as we begin to recognize the manifold relationships between the quality of a product and the quality of requirements from which it is developed. In their early empirical study, inconsistent, incomplete, or ambiguous requirements have a critical impact on the quality of the resulting software. Noting this for different kinds of projects, they concluded that the requirements for software do not arise naturally instead they need to be engineered. Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements. 8/162

9 A Software Requirements Specification (SRS) is a document, which is used as a communication between the customer and the supplier. When the software requirement specification is completed and is accepted by all parties, the end of the requirements engineering phase has been finished. After the acceptance phase, the requirements can be changed, but the changes must be tightly controlled. Both the customer and the supplier should edit the software requirement specification, as initially neither has both the knowledge of what is required (the supplier) and what is feasible (the customer) [1,2,3,5]. A software requirements specification has a number of purposes and contexts in which it is used. They can range from a company publishing a software requirement specification to companies for competitive tendering, or a company writing their own software requirement specification in response to a user requirement document. In the first case, the author of the document has to write the document in such a way that it is general enough as to allow a number of different suppliers to propose solutions, but at the same time containing any constraints, which must be applied. In the second instance, the software requirement specification is used to capture the users requirements and if any, highlight any inconsistencies and conflicting requirements and also may define software acceptance testing activities. Because software requirement specification in its most basic form is a formal document used in communicating the software requirements between the customer and the developer, so the minimum amount of information that the software requirement specification should contain is a list of requirements, which has been agreed by both parties. However the requirements will only give a narrow view of the system, so more information is required to place the system into a context which defines the purpose of the system, an overview of the systems functions and the type of user that the system will have. This additional information will aid the developer in creating a software system, which will be aimed at the users ability and the client s function. 9/162

10 There are many good definitions of Software Requirements Specifications that will provide us a good basis upon which we can both define a good specification and help us identify deficiencies in our past efforts. There is also a lot of good stuff on the web about writing good specifications. The problem is not lack of knowledge about how to create a correctly formatted specification or even what should go into the specification. The problem is that we don't follow the definitions. The IEEE is an excellent source for definitions of System and Software Specifications [4,5,8,12]. Essential to having a good Software Specification is having a well-defined System Specification. One of the main standard for software specification calls IEEE-830 and the equivalent IEEE standard for system specification that is IEEE STDF However, for most purposes in smaller systems, the same templates (system or software template) can be used for both. There are many distinct roles in each software development project, while the same person often plays more than one role on a given project, it is most useful to consider how every role on the project uses the requirements document. Below is a list of project roles and the way for each role may uses the requirements document. Need to remember that each of these roles uses the document in a different way; indeed some may use only some parts of the document. Software Development Development Project Leader Reason for Using the Requirements Document 1. Scope the project; divide the project in to Phases. 2. Obtain agreements from the business expert, project sponsor, and the development manager on the scope and schedule for phases. 3. Track development progress. 10/162

11 Requirements Analyst 1. Elicit and document business Requirements. 2. Test the application against the Requirements. Development Team Member Testers User Documentation Specialist Maintenance Team Member Design and code the application. Verify that application conforms to requirements. Produce user documentation. 1. Learn the application to take over the production support from the development team. 2. Support users in production. Project Sponsor Business Expert (often designated by the project sponsor) Provide the motivation for the project Sign off on the planned phases and their scope Confirm that the requirements reflect the business needs Sign off on the planned phases and their scope. Table 1: Users of requirements documents 11/162

12 The Requirements Generation process is placed at the beginning in most software development lifecycles. In itself, the process is composed of the activities listed below. Requirements Elicitation - Software requirements are elicited from people or derived from system requirements. An important precursor to the elicitation process is the problem synthesis process, during which the underlying issues are identify and customer needs are elicited. Requirements Analysis - is usually performed before the customer commits to the actual development process (design and implementation). The customer assesses the acceptable level of risk regarding the completeness, correctness, and technical and cost feasibility. Requirements Specification. Requirements elicited and analyzed in the preceding phases are documented and expressed in the form of a formal document (deliverable), often referred to as the Software Requirements Specification (SRS). Requirements Verification and Validation. Ensures that the requirements elicited and specified in the SRS adhere to the customer needs or the high level requirements. The requirements elicited are presented to diverse audiences for review and approval. Adherence of specified requirements to pre-defined quality attributes is also tested. Requirements Management - Any process must incorporate a management methodology that pervades through the entire process and facilitates communication effectively, in case any changes are made. 12/162

13 The vision is to create a requirements generation environment that provides tools and artifacts to capture requirements, and also embodies a model. If adhered to, the model ensures the production of unambiguous and complete requirements specification, which, most importantly, will also capture the customer intent. The model will be expressed at multiple abstraction levels providing information (guidelines) about low-level activities, and will lead the requirements engineer through the requirements generation process, the model will span the entire requirements generation process, addressing the activities of requirements elicitation, analysis, specification, validation and management. The model incorporates the following features: Decomposition of the requirements generation process to provide varying levels of detail. Constant verification and validation activities ensuring that the customer s intent is always captured and verified. The DorsGen tool codifies the activities described in the model. It leads the user (typically the requirements engineer) through the requirements generation process by providing appropriate guidelines, tools and artifacts at every step. It starts with activities related to the identification of the real problem motivating the need for a change, followed by elicitation and analysis of requirements. The final output produced by the interactive tool will be verified. In short, the tool will provide a guiding, synergistic structure for requirements generation activities. 13/162

14 Writing a clear and correct SRS document provides easy maintenance and enhancement of these systems during their deployed lifetime, but unfortunately there lots of problem in writing a SRS document like incorrectness, and inconsistence, today all software engineering agrees for the need of SRS management tool, which help the SRS writer to write a correct SRS document, this document describes a software tool, named SRS Generator (DorsGen), its goal, generating automatically a Software Requirements Documents. The SRS provides an organized way to collect all software requirements surrounding a project (or perhaps at a subsystem or feature level) into one document. In these days of automation and visual modeling, we often find ourselves with several different tools for collecting these requirements. The complete set of requirements may indeed be found in several different artifacts accessible by multiple tools. For example, you might find it useful to collect some (or all) of the functional requirements of your system in use cases and you might find it handy to use a tool appropriate to the needs of defining the use-case model. On the other hand, you might find it appropriate to collect traditionally stated natural-language requirements (such as non-functional requirements, design constraints, etc.) The DorsGen tool tries to solve the programmer problem of writing clearly SRS document. DorsGen is easy-to-use software tool for generating automatically SRS document and diagrams as Context Diagram [5], Use Case Diagram [5], Data Dictionary [5], DFD [1,2,3,4], Class Diagram [6,7]. Drawing those diagram with the DorsGen requires no artistic talent, users simply drag and drop ready-made graphic elements to create professional-looking diagrams quickly and easily, the draw diagram will generated to a SRS document in MS-Word format. The generated document structure and the diagrams type will be according to user definition. 14/162

15 Thesis structure The thesis organized as follows: Chapter 2 presents the SRS content, SRS benefits, SRS characteristics and SRS diagrams, this chapter also describe common standard for writing an SRS document. Chapter 3 presents the Aspect concept, this chapter also describes the benefits of using aspects oriented programming. Chapter 4 defines the user needs and user requirement from a tool in order to write easily a SRS document, this chapter also investigate other software tools (that exist in the market), which enable the user to write an SRS document and/or draw SRS diagrams. Chapter 5 detailed the DorsGen tools and its advantage upon other tools, and its abilities and its features. Chapter 6 defines a model for specifying requirement and how the DorsGen helps to specify it. Chapter 7 summarized the work and includes a feature work. 15/162

16 2. What is a software requirement specification The main purpose of this chapter is to provide a detailed description of Software Requirements Specification (SRS) [1,2,3,5,15,16]. An SRS is basically an organization's understanding (in writing) of a customer or potential client's software requirements and dependencies at a particular point in time (usually) prior to any actual design or development work. It's a two-way insurance policy that assures that both the client and the organization understand the other's requirements from that perspective at a given point in time. The SRS document itself states in precise and explicit language those functions and capabilities a software system must provide, as well as states any required constraints by which the system must abide. The SRS also functions as a blueprint for completing a project with as little cost growth as possible. The SRS is often referred to as the "parent" document because all subsequent project management documents, such as design specifications, statements of work, software architecture specifications, testing and validation plans, and documentation plans, are related to it. It's important to note that an SRS contains functional and nonfunctional requirements only, it doesn't offer design suggestions, and possible solutions to technology or business issues, or any other information other than what the development team understands the customer's software requirements to be. A well-designed, well-written SRS accomplishes four major goals: It provides feedback to the customer - An SRS is the customer's assurance that the development organization understands the issues or problems to be solved and the software behavior necessary to address those problems. Therefore, the SRS should be written in natural language (versus a formal language, explained later in this article), in an unambiguous manner that may also include charts, tables, data flow diagrams, decision tables, and so on. 16/162

17 It decomposes the problem into component parts - The simple act of writing down software requirements in a well-designed format organizes information, places borders around the problem, solidifies ideas, and helps break down the problem into its component parts in an orderly fashion. It serves as an input to the design specification - As mentioned previously, the SRS serves as the parent document to subsequent documents, such as the software design specification and statement of work. Therefore, the SRS must contain sufficient detail in the functional software requirements so that a design solution can be devised. It serves as a product validation check - The SRS also serves as the parent document for testing and validation strategies that will be applied to the requirements for verification. SRSs are typically developed during the first stages of Requirements Development, which is the initial product development phase in which information is gathered about what requirements are needed and not. This information analysis or needs analysis of the customer or client's current business environment. The actual specification, then, is written after the requirements have been gathered and analyzed. To the customers, suppliers, and other individuals, a good SRS should provide several specific benefits, such as the following [28]: Establish the basis for agreement between the customers and the suppliers on what the software product is to do or not to do- The complete description of the functions to be performed by the software specified in the SRS will assist the potential users to determine if the software specified meets their needs or how the software must be modified to meet their needs. Reduce the development effort - The preparation of the SRS forces the various concerned groups in the customerױs organization to consider rigorously all of the requirements before design begins and reduces later redesign, recoding, and retesting. Careful review of the requirements in the SRS can reveal 17/162

18 omissions, misunderstandings, and inconsistencies early in the development cycle when these problems are easier to correct. Provide a basis for estimating costs and schedules - The description of the product to be developed as given in the SRS is a realistic basis for estimating project costs and can be used to obtain approval for bids or price estimates. Provide a baseline for validation and verification - Organizations can develop their validation and verification plans much more productively from a good SRS. As a part of the development contract, the SRS provides a baseline against which compliance can be measured. Facilitate transfer - The SRS makes it easier to transfer the software product to new users or new machines. Customers thus find it easier to transfer the software to other parts of their organization, and suppliers find it easier to transfer it to new customers. Serve as a basis for enhancement - Because the SRS discusses the product but not the project that developed it, the SRS serves as a basis for later enhancement of the finished product. The SRS may need to be altered, but it does provide a foundation for continued of production. The basic issues that an SRS writer should address are the following [28]: Functional requirements - Functional requirements define the fundamental actions that must take place in the software in accepting and processing the inputs and in processing and generating the outputs. These are generally listed of statements starting with "The system shall [See chapter 2.1]. 18/162

19 External interfaces - How does the software interact with people, the system s hardware, other hardware, and other software. The SRS document should identify the external interfaces of the application. Provide an External Interface Diagram to aid in this description. Identify each external interface by name and provide a brief description of each interface. Reference any existing documentation for each interface. The External interfaces content and format should be as follows: o Name of item o Description of purpose o Source of input or destination of output o Valid range, accuracy and/or tolerance o Units of measure o Timing o Relationships to other inputs/outputs o Data formats o Command formats Design constraints imposed on an implementation - Are they re any required standards in effect, implementation language, and policies for database integrity, resource limits, operating environments. Non-functional requirements - This is a full listing of the rest of the nonfunctional requirements such as performance requirements, logical database requirements, design constraints, software system attributes, standards compliance and other non-functional requirements. [See chapter 2.2]. 19/162

20 2.1 Functional requirements Functional requirements capture the intended behavior of the system. This behavior may be expressed as services, tasks or functions the system is required to perform. Functional requirements should provide a short description of the functions to be performed by the software, i.e. what the product should do. This description must be in a form understandable to users, operators, and clients. Functional requirements also itemize the detailed functional requirements associated with the system. These are the software capabilities that must be present in order for the user to carry out the services provided by the feature, or to execute the use case. Include how the product should respond to anticipated error conditions or invalid inputs. Requirements should be concise, complete, unambiguous, verifiable, and necessary. Each functional requirement should be specified in a format similar to the following: Purpose - a description of the functional requirement and its reason(s) Inputs - which inputs, in what form/format will inputs arrive, from what sources input will be derived, legal domains of each input element processing describes the outcome rather than the implementation, include any validity checks on the data, exact timing of each operation (if needed), how to handle unexpected or abnormal situations. Outputs - the form, shape, destination, and volume of the output, output timing, range of parameters in the output, unit measure of the output, process by which the output is stored or destroyed, process for handling error messages produced as output Functional decomposition Functional decomposition was originally applied to software requirements to abstract from coding details. Functional decomposition focuses on understanding and specifying what processing the software is required to do. The general 20/162

21 strategy is to define the required behavior as a mapping from inputs to outputs. Ideally, the analysis precedes top down, first identifying the function associated with the system as a whole. Each subsequent step decomposes the set of functions into steps or sub functions. The result is a hierarchy of functions and the definitions of the functional interfaces. Each level of the hierarchy adds detail about the processing steps necessary to accomplish the more abstract function above. The function above controls the processing of its sub functions. In a complete decomposition, the functional hierarchy specifies the calls structure of the implementation. The advantage of functional decomposition is that the specification is written using the language and concepts of the implementers. It communicates well to the designers and coders. It is written in terms of the solution space so the transition to design and code is straightforward. Common complaints are that functional specifications are difficult to communicate, introduce design decisions prematurely, and difficult to use or change. Because functional specifications are written in the language of implementation, people who are not software or systems experts find them difficult to understand. Since there are inevitably many possible ways of decomposing functions into sub functions, the analyst must make decisions that are not requirements. Finally, since the processing needed in one step depends strongly on what has been done the previous step, functional decomposition results in components that are closely coupled. Understanding or changing one function requires understanding or changing all the related functions. As software has increased in complexity and become more visible to non technical people, the need for methods addressing the weaknesses of functional decomposition has likewise increased. 21/162

22 2.2 Non-functional requirements A successful software system is the one that not only realizes its desired functional requirements but also meets its non-functional requirements (NFR). Basically functional requirements describe what the system should do for the users. While non-functional requirements, also called "quality attributes," are constraints on various attributes of the system s functions or tasks. They are used to specify system characteristics that are required for acceptance of the system by the end user. Examples of such non-functional requirements are cost, reliability, security, accuracy, performance, and modifiability etc. Architectural frameworks have been proposed as a solution to support the design and analysis of non-functional requirements such as performance, security, adaptability, etc. A significant benefit of performing such analysis work is to detect and remove defects earlier in the design phase. However, the nonfunctional requirements of a system have mainly been addressed in the literature independently making it difficult for the design and analysis of a system with respect to a collection of these interacting, or tangled, properties as software systems continue to increase in size and complexity, researchers are motivated to investigate software engineering methodologies that support the effective development of large-scale systems with desired quality attributes, such as performance, security, accessibility, reusability, etc. The specification and analysis of these attributes at the architecture design level has received significant attention as a means to identify a system s potential problems (e.g., system s incompleteness and inconsistency) and to ensure that quality attributes are built into the system, thus reducing development cost and time. Although non-functional requirements may be less visible in a requirement specification, they have a critical role during the process of system development. Non-functional requirements can serve as selection criteria to help designers to make rational decisions among competing designs, which in turn affect a system s ultimate implementation. Furthermore, they direct architects and designers to consider system s quality and address them in the design at a very early stage. Under the guidance of non-functional requirements, a systematic and 22/162

23 pragmatic approach is possible for developing software systems towards desired quality attributes. When considering a system s non-functional requirements, an issue that cannot be overlooked is, in reality, a system may need to meet two or more nonfunctional requirements and these non-functional requirements may conflict or be synergistic with each other. For example, security may negatively affect performance, since higher security may require the system to do extra verification on a user s input data, support encryption and decryption, manage certificates, etc., leading to lower performance. Another example is that many non-functional requirements (e.g., performance, security, availability, etc.) negatively affect cost as developing a high performance system may demand more manpower and time. Therefore, tradeoff analysis work between non-functional requirements is needed in an architecture development approach. Currently, such an approach is not available in the literature. 23/162

24 2.3 SRS characteristics A complete SRS is more than a long list of functional requirements. It also includes external interface descriptions and nonfunctional requirements such as quality attributes and performance expectations [28]. The following characteristic defines that a good SRS document is: Correct - Of course you want the specification to be correct. No one writes a specification that they know is incorrect. The discipline is keeping the specification up to date when you find things that are not correct. Unambiguous - As the Oxford English dictionary states the word unambiguous means "not having two or more possible meanings". This means that each requirement can have one and only one interpretation. If it is unavoidable to use an ambiguous term in the requirements specification, then there should be clarification text describing the context of the term. One way of removing ambiguity is to use a formal requirements specification language. The advantage to using a formal language is the relative ease of detecting errors by using lexical syntactic analyzers to detect ambiguity. The disadvantage of using a formal requirements specification language is the extra learning time and loss of understanding of the system by the client. Complete - For a software requirements specification to be complete, it must have the following properties: Description of all major requirements relating to functionality, performance, design constraints and external interfaces. Definition of the response of the software system to all reasonable situations. Be fully defined, if there are sections in the software requirements specification still to be defined, the software requirements specification is not complete. 24/162

25 Consistent - A software requirement specification is consistent if none of the requirements conflict. There are a number of different types of confliction: Multiple descriptors - This is where two or more words are used to reference the same item, i.e. where the term cue and prompt are used interchangeably. Opposing physical requirements - This is where the description of real world objects clash, e.g. one requirement states that the warning indicator is orange, and another states that the indicator is red. Opposing functional requirements - This is where functional characteristics conflict, e.g. perform function X after both A and B has occurred, or perform function X after A or B has occurred. Modifiable The writer must be able to revise the SRS when necessary and maintain a history of changes made to each requirement. This means that each requirement be uniquely labeled and expressed separately from other requirements so you can refer to it unambiguously. Traceable - The ability to trace (forwards and backwards) a requirement from its conception through its specification to its subsequent design, implementation and test. Verifiable - A software requirement specification is verifiable if all of the requirements contained within the specification are verifiable. A requirement is verifiable if there exists a finite cost-effective method by which a person or machine can check that the software product meets the requirement. Non-verifiable requirements include "The system should have a good user interface" or "the software must work well under most conditions" because the performance words of good, well and most are subjective and open to interpretation. If a method cannot be devised to determine whether the software meets a requirement, then the requirement should be removed or revised. 25/162

26 2.4 SRS standards The first and biggest step to writing an SRS is to select an existing template that you can fine tune for your organizational needs. There s not a standard specification template for all projects in all industries because the individual requirements that populate an SRS are unique not only from company to company, but also from project to project within any one company. The key is to select an existing template or specification to begin with, and then adapt it to meet your needs. When recommending using existing templates, it not advocating simply copying a template from available resources and using them as your own, it suggests that you use available templates as guides for developing your own. It would be almost impossible to find a specification or specification template that meets your particular project requirements exactly. But using other templates as guides is recommended in the literature on specification development. Two widely used software requirement specifications are presented, one is a military standard, and the other is a recommended practice put together by commercial organizations: IEEE 830 This American standard gives an outline to the contents and a detailed description of the contents of software requirements specification [See appendix 1]. MIL-STD-498 Military Standard, which approved for use by all Departments and Agencies of the Department of Defense. This standard merges DOD-STD-2167A and DOD-STD-7935A to define a set of activities and documentation suitable for the development of both weapon systems and Automated Information Systems. [See appendix 2]. 26/162

27 There are a number of different layouts provided for the specific requirements section of the software requirements specification. The templates provided cover organized by mode, organized by class, organized by object, organized by feature, organized by stimulus, organized by functional hierarchy and showing multiple organizations. 27/162

28 2.5 How to specify requirements When detailing how requirements are specified, two factors need to be taken into consideration. Firstly the notation used to describe the requirements and secondly the way in which the notation is to be presented to the reader of the requirements specification document. Notations - there are problems associated with specifying the requirements for a system, in any representation that is not natural language. This is due to the problem of the client not being able to understand the contents of the document, and therefore would not able to agree that the requirement specification correctly describes this. With this in mind the requirements engineer must know the limitations of the client s knowledge and their ability to understand any modeling technique that is used to describe the software system. Advantages to using modeling techniques as opposed to natural language include a higher level of specification validation, which is not available for natural language, a large reduction in the likelihood of ambiguity, which gives the specification higher integrity, and in most modeling techniques consistency checking is simplified and even automated when a software tool supports the modeling technique. Examples of modeling techniques used in software requirements specifications include schemas like data flow diagrams, entity relationship diagrams, state transition diagrams, flow charts and storyboards. Representation of requirements - when diagrammatic techniques such as data-flow diagrams are used to model requirements, they inherently have a predefined method of presentation. With a data-flow diagram you would expect to see a context diagram, followed by the level zero data-flow diagram. Following the level 0 data-flow diagram you would expect to see the level one diagrams, followed by the level two diagrams, etc. The following are some of diagrammatic techniques representing requirements: Context Diagram. Use Case 28/162

29 Data Dictionary. DFD Diagram. Class Diagram. State Chart Sequence Diagram Context diagram A Context Diagram is a black box visual representation of the proposed system, the external elements, known as terminators, which will interact with the system, and the data, which flows between the terminators and the system. Terminators can include individual users, other systems, other data stores, and other organizations [5]. The Context Diagram clarifies the boundary between system and environment, visually representing what the system will do for the organization. It is an ideal tool to use when discussing which functionality should be provided by the system and which functionality should remain outside of the system. However, the context diagram only acts as a tool within the decision making process but does not actually provide any guidance on how to make the decision. The Context Diagram is considered the highest-level data flow diagram and is used when validating data inputs and outputs in lower level data flow diagrams. 29/162

30 2.5.2 Use case diagram Use case is the process of describing the system behavior of the target system from an external point of view. A Use Case diagrams identify the functionality provided by the system (use cases), the users who interact with the system (actors), and the association between the users and the functionality. Use Cases are used in the Analysis phase of software development to articulate the high-level requirements of the system [5]. Use case analysis is one of the first and primary means of gathering requirements in the behavioral methodology. Use cases are a standard technique for gathering requirements in many modern software development methodologies. In fact, use cases are included in the Unified Modeling Language (UML), which has become the de facto industry standard software artifact notation. More formally, a use case is made up of a set of scenarios. Each scenario is a sequence of steps that encompass an interaction between an actor/external entity and a system. The use case brings scenarios together that accomplish a specific goal of the user. Textually describing the steps required and any alternative actions at each step can specify a use case. 30/162

31 2.5.3 Data dictionary The data dictionary provides a complete description of record layouts and indexes of the database for validation and to insure efficient data access [5]. Data dictionary is also an organized listing of all the data elements within a system (precise and rigorous definitions) The data dictionary collect, coordinate and confirm what a specific data term means to user and system analyst. A data dictionary contain: Information about system data. Relationships between entries. Project requirements and deliverables. Project management information. The data dictionary may contain basis information for: Data structure. Data store Data structure Describe the composition of aggregate packets of data (data structure) moving along the flow. The data structure is a group of smaller structures and elements with algebraic notation that is used to represent the structure[5]. One of the algebraic notations is called BNF [12,31,32], BNF is an acronym for "Backus Naur Form". John Backus and Peter Naur introduced for the first time a formal notation to describe the syntax of a given language. 31/162

32 Data store Describe the composition of packet of data in stores, a data store responds to requests to store and access data. It does not generate any operations. A data store allows values to be accessed in an order different from the order in which they were generated [5]. Data store contain minimal of all base elements as well as many derived elements and create for each different data entity (person, place or thing being stored). Data store represents a location where the data is not moving but is being stored passively for future use; Data stores are represented by a small narrow rectangle. 32/162

33 2.5.4 DFD diagram Data flow diagrams (DFDs) reveal relationships among and between the various components in a program or system. DFDs are an important technique for modeling a system s high-level detail by showing how input data is transformed to output results through a sequence of functional transformations. DFDs consist of four major components: entities, processes, data stores, and data flows. The symbols used to depict how these components interact in a system are simple and easy to understand, however, there are several DFD models to work from, each having its own symbol. DFD syntax does remain constant by using simple verb and noun constructs. Such a syntactical relationship of DFDs makes them ideal for object-oriented analysis and parsing functional specifications into precise DFDs for the systems analyst [5]. When it comes to conveying how information data flows through systems (and how that data is transformed in the process), data flow diagrams (DFDs) are the method of choice over technical descriptions for three principal reasons. 1. DFDs are easier to understand by technical and nontechnical audiences. 2. DFDs can provide a high level system overview, complete with boundaries and connections to other systems 3. DFDs can provide a detailed representation of system components DFDs help system designers and others during initial analysis stages visualize a current system or one that may be necessary to meet new requirements. Systems analysts prefer working with DFDs, particularly when they require a clear understanding of the boundary between existing systems and postulated systems. DFDs represent the following: 1. External devices sending and receiving data 2. Processes that change that data 3. Data flows themselves 33/162

34 4. Data storage locations The hierarchical DFD typically consists of a top-level diagram (Level 0) underlain by cascading lower level diagrams (Level 1, Level 2 ) that represent different parts of the system. The DFD objectives are: To graphically document boundaries of a system. To provide hierarchical breakdown of the system. To show movement of information between a system and its environment. To document information flows within the system. To aid communication between users and developers. 34/162

35 2.5.5 Class diagram A class diagram consists of a group of classes and interfaces reflecting important entities of the business domain of the system being modeled, and the relationships between these classes and interfaces [6,7]. The classes and interfaces in the diagram represent the members of a family tree and the relationships between the classes are analogous to relationships between members in a family tree. Interestingly, classes in a class diagram are interconnected in a hierarchical fashion, like a set of parent classes (the grand patriarch or matriarch of the family, as the case may be) and related child classes under the parent classes. Similarly, a software application is comprised of classes and a diagram depicting the relationship between each of these classes would be the class diagram. By definition, a class diagram is a diagram showing a collection of classes and interfaces, along with the collaborations and relationships among classes and interfaces [6]. A class diagram is a pictorial representation of the detailed system design. Design experts who understand the rules of modeling and designing systems design the system s class diagrams. A thing to remember is that a class diagram is a static view of a system. The structure of a system is represented using class diagrams. Class diagrams are referenced time and again by the developers while implementing the system. 35/162

36 2.5.6 State Chart diagram State chart diagrams represent the behavior of entities capable of dynamic behavior by specifying its response to the receipt of event in stances. Typically, it is used for describing the behavior of classes, but state charts may also describe the behavior of other model entities such as use-cases, actors, subsystems, operations, or methods. A state chart diagram shows the sequences of states that an object or an interaction goes through during its life in response to received stimuli, together with its responses and actions. State diagram describe all of the possible states of an object as events acting upon it. Each diagram usually represents objects of a single class and tracks the different states of its objects through the system. An object's set of attributes at any one stable time is termed a state, and it can change to other States by means of Transitions, triggered by Events State charts describe how the functionality of a system relates to the state in which it exists at any one point in time, and how its state changes in response to events acting upon it. It relates things happening to an object to changes in the object. Eg. When a switch is turned on, a lamp changes its situation from off to on. After a while a washing machine is changing from washing to rinsing Sequence diagram A Sequence diagram depicts the sequence of actions that occur in a system. The invocation of methods in each object, and the order in which the invocation occurs is captured in a Sequence diagram. This makes the Sequence diagram a very useful tool to easily represent the dynamic behavior of a system. A Sequence diagram is two-dimensional in nature. On the horizontal axis, it shows the life of the object that it represents, while on the vertical axis, it shows the sequence of the creation or invocation of these objects. Because it uses class name and object name references, the Sequence diagram is very useful in elaborating and detailing the dynamic design and the sequence and origin of invocation of objects. 36/162

37 3. Aspect oriented approach When Object-Oriented (OO) programming entered the mainstream of software development, it had a dramatic effect on how software was developed. Developers could visualize systems as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. The only problem with OO programming is that it is essentially static, and a change in requirements can have a profound impact on development timelines [19,20,21]. Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops. Consider an example: many of you have developed simple web applications that use servlets as the entry point, where a servlet accepts the values of a HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. The first cut of the servlet may be very simple, with only the minimum amount of code required to fulfill the use case being modeled. The code, however, often inflates to three to four times its original size by the time secondary requirements such as exception handling, security, and logging have been implemented. AOP allows us to dynamically modify our static model to include the code required to fulfill the requirements without having to modify the original static model (in fact, we don't even need to have the original code). Better still, we can often keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. 37/162

38 3.1 Crosscutting concerns Programming languages evolved from machine codes and assembly languages to a variety of paradigms such as formula translation, procedural programming, functional programming, logic programming, and object-oriented programming. The programming technology advancement has improved the ability of the software developer to achieve clear separation of concerns, or the ability to identify, encapsulate, and manipulate only the parts of software that are relevant to a particular concept, goal, or purpose. Nowadays, object-oriented programming has become the dominant programming paradigm where a problem is decomposed into objects that abstract behavior and data in a single entity. Object technology, including OO methodologies, analysis and design tools, and OO programming language, reduces the complexity in writing and maintaining complex applications such as distributed applications and graphical userinterfaces [17,20]. Although OO technology offers greater ability for separation of concerns, it still has difficulty localizing concerns, which do not fit naturally into a single program module, or even several closely related program modules. Concerns can range from high-level notions such as security and quality of services to low-level notions like buffering, caching, and logging. They can also be functional, such as business logics, or non-functional, such as synchronization. Some concerns usually couple with a few objects, yet achieve good cohesion. Other concerns, such as logging, will intertwine with many highly unrelated modules. In addition, crosscutting concerns cannot be neatly separately from each other. Consider the UML for a simple figure editor, there are two concerns for the editor: keep track of the position of each figure element (data concern) and update the display whenever an element has moved (feature concern). The OO design nicely decomposes the graphical element so that the data concern is neatly localized. However, the feature concern must appear in every movement method, crosscutting the data concern. The software could be designed around the 38/162

39 feature concern, but then the data concern would crosscut concern for display update. Other concerns cannot be encapsulated within the dominant modules, ending up being scattered across many modules and tangled with one another. This phenomenon is called the tyranny of the dominant decomposition, in which one dominant way of decomposition imposes software structure that makes separating of concerns difficult or impossible. This problem is difficult to avoid in many systems designed in OO paradigm. Consider the problem of implementing synchronization between concurrent objects in the OO paradigm. The implementation of the synchronization policy, such as multiple-readers/single-writer, must be embedded into the definition of the objects whose activity is being synchronized, causing tangling of aspects. Code reuse is minimal, while maintenance cost increases. For Example Logging - is frequently used in distributed applications to aid debugging by tracing method calls. Suppose as part of e-commerce project convention, all developers must do logging at both the beginning and the end of each function body. Clearly, logging crosscuts all classes that have at least one function. As another example of crosscutting concerns consider a billing system for telephone conferences. Assume that the system needs to store the duration and cost of every transacted call as a concern for the system. There may be different ways to achieve this call tracking. The telephone billing system would have the following classes: Customer, Call, and Connection, among others. Procedures dealing with transaction register, timing and cost determination would act upon these classes and there is no single class that performs the needed call tracking methods on its own. As illustrated in figure 1 the elements in square C) would not pertain only to classes Connection A) and Customer B), the data and methods in square C) represent an aspect, actually two aspects. 39/162

40 Connection -Pending : int -Complete : int -State : int +<<Contractor>> Connection() +GetState() +GetCaller() +GetReceiver() +Complete() +Drop() +Connetcs() Costumer -Name : char -AreaCode : int -Calls : int +<<Constructor>> Costomer() +AddCall() +RemoveCall() +GetAreaCode() +Call() +HungUp() <<Cross Cutting "Billing Concern" data and methodes>> -TotalCharge : long -TotalConnectTime : float -Payer : Costumer -CallRate : int -Timer : int +GetTotalConnectTime() +GetTimer() +GetTotalCharge() +AddCharge() A) B) C) Figure 1: Billing system crosscutting example AOP aims at identifying and specifying such crosscutting concerns in separate modules tempering the scattering and tangling of concerns across different units providing one more dimension to modularize software. 40/162

41 3.2 What is an aspect Aspects are one kind of concern in software development. It is the unit of crosscutting modularity, and it holds any of the crosscutting elements. An aspect may be related to another aspect by inheritance relationship, or an aspect may be related to other aspects by a precedence relationship, which ensures a deterministic behavior when multiple aspects affect the some parts of the system. Many kinds crosscutting concerns like logging, caching, security checking and exception handling may be designed as separately aspects in a software system. This illustration is based on the billing system example introduced in the previous section. Connection Customer Billing and timing related data and methods Figure 2: Modular units and aspect Aspects can be system properties involving more than one functional component, crossing the static and dynamic structure of a program, they affect and modify several classes. This means that aspects might be static or dynamic properties that affect not only the behavioral definition of classes, but also the data structure defined by the classes. Although the above gives a first definition of an aspect, we still have to consider ways to identify them. It is to be noted that aspects can be identified in the different software development stages, bearing in mind that the main characteristics of an aspect are two: it is a cross-cutting concern, and it relates to the dependency between concerns in a software system. Defining and identifying 41/162

42 an aspect is a matter as yet under study. So far, there seems to be no guiding principles that unmistakably identify aspects out of requirements specification. Recently, some authors have defined that issues that are not well localized in functional designs such as: synchronization, component interaction, persistency, security control, fault tolerance mechanisms, quality of service, and the like, are concerns that are typical candidate aspects. Another guideline to identify aspects is that they are usually expressed by small code fragments scattered throughout several functional components [9]. Compatibility, availability and security requirements are crosscutting concerns. Also exception handling, multi-object protocols, synchronization, and resource sharing would be extended across the source code if only using traditional implementation techniques. There is a need for a clear definition of aspect, even before we aim at achieving aspect identification, weaving, and modeling of aspects. Take for instance the early stage of software requirements; it is at that stage that many of the later difficulties in software development can be generated. Therefore a great effort is on progress to identify aspects at the requirements stage. Kiselev at [10] points out a simplified rule of thumb for aspect identification: a property that must be implemented is A component, if it can be cleanly encapsulated in a generalized procedure. By cleanly, we mean well localized, and easily accessed and composed as necessary. An aspect, if it cannot be cleanly encapsulated in a generalized procedure. Aspects tend not to be units of the system s functional decomposition, but rather to be properties that affect the performance or semantics of the components in systemic ways. Examples of aspects include memory access patterns and synchronization of concurrent objects. 42/162

43 This simple rule of thumb points in the right direction, because it is consistent with the concept of aspect. Nevertheless, there is still a need for a framework that helps program designers identifying aspects in an automated or semi-automated way. Our critique to this simple rule is that it does not help in distinguishing what is an aspect and what is not an aspect, for instance, would a synchronization protocol be an aspect or would only a part of the protocol be considered an aspect?, would every call to a database in a front-end be considered an aspect just because it might be carried out in different parts of the front-end?, furthermore, how useful would it be to consider systemic concerns such as quality of service or performance as aspects? 43/162

44 3.3 Aspect-oriented programming The principle of separation of concerns has long been the core of software engineering. It helps software engineers to manage the complexity of software system development. This principle refers to the ability to identify, encapsulate, and manipulate those parts of software that are relevant to a particular concern (concept, goal, purpose, non-functional requirements, etc.). Concerns are the primary motivation for organizing and decomposing software into manageable and comprehensible parts. Some kinds of concerns may be relevant to different developers in different roles, or at different stages of the software lifecycle. For example, the prevalent concern in object-oriented programming is the class, which encapsulates data concerns. Feature concerns, like printing, persistence, and display capabilities, are also common, as are concerns like aspects, roles, variants, and configurations. Appropriate separation of concerns has been hypothesized to reduce software complexity and improve comprehensibility, promote traceability, facilitate reuse, non-invasive adaptation, customization, and evolution, and simplify component integration [19,20,21]. Two different levels of separation of concerns have been distinguished; the first one is the conceptual level. At this level, the separation of concerns needs to address two issues: provide a clear definition and conceptual identification of each concern that distinguishes it from the others, and ensure that the individual concepts are primitive in the sense that they are not composition of several concepts. The second one is the implementation level. At this level, the separation of concerns needs to provide an adequate organization that isolates the concerns. The goal at implementation level is to separate the blocks of code, which address the different concerns, and provide for a loose coupling of them. The idea of AOP is that computer systems are better programmed by separately specifying the various concerns (properties or areas of interest) of a system and some description of their relationships, and then relying on mechanisms in the underlying AOP environment to weave or compose them together into a coherent system. Further, AOP precisely defined the terms component and aspect. If a system property can be clearly encapsulated in a procedure (i.e., object, method, 44/162

45 procedure, API), it is a component. Otherwise the property should be called as aspect. Therefore, components tend to be units of the system s functional decomposition, while aspects tend to be properties that affect the performance or semantics of the components in systemic ways. The process of merging aspects with classes before a compiler to produce the executable program is named aspect wavering. There are two ways in which classes and aspects can be woven: static or dynamic. Static weaving means to modify the source code of a class by inserting aspect-specific statements at join points [See Section 3.4]. In this way, aspect code is inline into classes. The result is highly optimized woven code, whose execution speed is comparable to that of code writing without using aspects. Hence, static weaving prevents that the additional abstraction level introduced by aspect-oriented programming causes a negative impact on a program s performance. However, static weaving makes it difficult to later identify aspect-specific statements in woven code and aspects cannot be modified flexibly. Dynamic weaving means to merge aspects and classes at runtime. In this way, classes and woven aspects are kept separate from each other and the weaver can dynamically add, adapt, or remove aspects at any time. One obvious problem with the dynamic problem is it can be time consuming and its implementation is difficult. AOP is a new technology for separating crosscutting concerns into aspects. With AOP, we start by implementing our project using our OO language (for example, Java), and then we deal separately with crosscutting concerns in our code by implementing aspects. Finally, both the code and aspects are combined into a final executable form using an aspect weaver. As a result, a single aspect can contribute to the implementation of a number of methods, modules, or objects, increasing both reusability and maintainability of the code. 45/162

46 3.4 AspectJ The aspect oriented programming language AspectJ is an extension to the object oriented language Java. This extension is accomplished through new concepts like: introductions, pointcuts, and advices. AspectJ has been developed as an Open Source Tool at XEROX-PARC. It has been created as a general purpose AO language that works as an integrated extension to Java and allows for static and dynamic crosscutting. The use of this AO language can be based on the identification of two broad categories of aspects: Development Aspects and Production Aspects. On the one hand, when dealing with developing aspects the language can be used to facilitate tasks such as: debugging, testing and performance tuning of applications. On the other hand, when dealing with production aspects it can be used for implementing functionality intended to be included in applications. In general terms, the language is used once the java classes that reflect the business logic have been developed, after that the aspects that address crosscutting concerns can be developed and woven into the application. The language relies on three key elements, introductions, pointcuts, and advices. AspectJ also known as inter-type declarations, declarations about a program s structure that provide a mechanism for adding new static as well as behavioral elements in the class structure. According to this, an aspect can be used to add new methods to a class, or declare that a class extends a super class. Inter-type declarations affect the static type hierarchy of programs, they implement static cross-cutting over the program. Inter-type declarations allow the programmer to modify classes by adding fields, methods or even changing the hierarchical structure. The type of members that can be declared by using inter-type declarations is: Fields Constructor Concrete or Abstract methods 46/162

47 Now, let us explore declarations that affect the dynamic structure of a program: Join Point, Point Cuts and Advices. Join Points - Join Points (JP) are special well-defined points in the execution flow of the program. These include method calls, object creation, exception execution, attribute value assignment, and the like. Each one has a special syntax. For instance, let us have a look at one aspect from the sample Telecom Simulation. Package telecom } public aspect TimeLog { { after(timer t) : target(t) && call (*Timer.Start()) System.err.println( Timer Started : + t.starttime); } Taken apart from the whole code the section call(* Timer.start()) defines the point of the program execution flow to which the aspect will be connected. This brings us to the question of when and how will the aspect be executed. Pointcuts - Pointcuts help refer to the set of join points whose execution needs to be modified. A pointcut selects certain JP along with its context values. A pointcut specifies a name for a set of JP that can be referred to by more than one advice. An example of a pointcut follows: pointcut iohandler(): within(myclass) && handler(ioexception); This pointcut selects JPs when exceptions of type IOException are handled inside the code defined by class MyClass. Advices - Advices contain the executable code to be implemented when pointcuts are reached. An Advice is the actual implementation of an aspect. In the case of the advices the developer must also determine when the advice is to be executed. There are three possibilities: 47/162

48 before the JP itself, after the JP, or around or instead the JP. In the given example the execution timing is specified by the key word: after at the beginning of the pointcut specification. There are two additional possibilities regarding the after keyword, those are after throwing and after finally. 48/162

49 3.5 Aspect-oriented design Aspect-Oriented design (AOD) is a relatively young area, and design knowledge, including generic design patterns and guidelines. Some AOD-related principles and properties have already emerged. However, there are some well-known principles in software engineering, currently recommended for the design of object-oriented systems, that may be affected by the concepts and pragmatics of aspect-oriented programming (AOP). These sets of principles, conventional or emergent, can be used as a starting point to suggest general guidelines for AOD. This section presents some general principles and principles used in objectoriented design. General principles: Separation of concerns - Every important issue (or concern) should be considered in isolation. Low coupling Every module should communicate with as few others as possible. Weak coupling - If two modules communicate at all, they should exchange as little information as possible. Information Hiding - All information about a component should be private to a component unless it is specifically declared public. Cohesion - Logically related components should be grouped together. Object-oriented principles: The Open Closed Principle - A module should be open for extension but closed for modification. The Liskov Substitution Principle - A derived class may substitute a base class. 49/162

50 The Dependency Inversion Principle - High-level modules should not depend upon low-level modules. Both should depend upon abstractions. Stable Dependencies Principle - Depend on the direction of stability. The Interface Segregation Principle - Many client specific interfaces are better than one general-purpose interface. The Law of Demeter - Each unit should have knowledge only about closely related units. Aspect-Oriented design can be defined as an approach to software design that supports separation of concerns along two dimensions of decomposition: a component-based dimension and an aspect-based dimension. AOD encompasses the process of aspect-oriented decomposition (in addition to object-oriented and algorithmic decomposition) and new design principles and properties. AOP techniques interfere with the principles described above by providing a new kind of modular dependency: the dependency between aspects and components. The aspect-oriented decomposition of AspectJ applications, for example, yields to a dependency structure in which the dependencies start at the aspect modules and point towards components. AspectJ also promotes the aspect-base dichotomy, that is, the adoption of a clear distinction between base components and aspects. Furthermore, it requires quantification support and may promote some level of component obliviousness. 50/162

51 4. SRS tools 4.1 Why are tools needed Documents play a central role in system development. The key activities of the system and software development lifecycle create information that must be recorded, retained and maintained. Such information includes process specifications, system and software requirement definitions, system and software design decisions, test procedures, etc. Documents remain the most prevalent means of recording and managing that information. Development activities in which the primary work-products are documents, suffer from a number of common problems. Although the same development activity (e.g., software requirement analysis and specification, test planning, etc.) recurs in different projects within an organization and even within the same project, developers often invest time in redefining the contents, organization and format of document work-product of such a development activity. Developers in most cases use a Copy & Paste operation, which means re-editing an existing requirement document in order to create a new one. This is a very problematic procedure, frequently causing inaccuracies and inconsistencies due to writers mistakes. These efforts and mistakes are both costly and time-consuming and, as a result, such document work-product suffer from a lack of uniformity between projects, between different types of document within the same project, and even between instances of the same document types within a single project. Moreover, such documents often suffer from incompetence. Since such documents are developed without adequate process foundation, they often suffer from acts of omission i.e., important aspects are not adequately treated or may even be totally omitted. Developing systems and software documents require highly experienced staff, and this also generates lack of document standardization and uniformity. A methodology or development approach often underlies a development document. Lack of document standardization often reflects a lack of coherent and uniformly applied development methodology or approach. This often results in a lack of conceptual integrity or even inconsistency, both in content and 51/162

52 terminology. Even in a case where a methodology is defined, there is no wellproven, automated mechanism for translating that methodology into a standard document structure. Organizations usually rely on templates or written procedures that are implemented manually. Templates, however, do not accommodate the many levels of detail and decision levels involved in writing a complex technical document. The development of large, complex systems presents many challenges to system engineers. Foremost among these is the ability to ensure that the final system satisfies the needs of the users, and provides for easy maintenance and enhancement of these systems during their deployed lifetime. These systems often change and evolve throughout their life cycle, making it difficult to trace the implemented system against the original and evolving user requirements. As recently as two decades ago, system engineers used pencil and paper to keep track of the requirements and system design of many complex systems. These elementary tools were relied upon to design and develop complex communication, transportation, space, military and medical systems. Although these tools were the best available at the time, managing the hundreds of complex requirements and design decisions during system engineering consumed much of the system engineer s time, leaving little opportunity to explore alternatives or perform analyses. During the 1980 s, system engineers used MS-Word processors, spreadsheets, databases and graphics packages as their tools for designing and developing complex systems. These tools provided a vast improvement over their predecessors, but still placed limitations on system engineers. Until very recently, it was not possible to transfer data from one tool to another, or from one system engineering environment to another. The tools did not support the ability to view requirement information at any abstract level. Most were designed to support a single user, and were not readily changeable to support the large team system development environment common in many organizations. Today, several specialized automated system-engineering tools are available. These tools have been made possible by improvements in computer technology including more storage capacity and faster processing speeds. With these 52/162

53 improvements, computer technology is now able to support the complex processes necessary for automation of system engineering. Along with the technology improvements, system engineering as a discipline has matured and become a definable process. Among the engineering automated tools are specialized requirement management tools. These tools concentrate on capturing requirements, managing, and producing requirement specifications. However, even these specialized tools have limitations. It is still difficult to relate the information stored within one tool to information stored in another. Many of the tools have automated an existing, document-driven system engineering process, rather than improve the process to support alternative abstract and visual mechanisms. The automated tools available today focus primarily on the information management aspect of requirement management, namely traceability and organization (with a few emerging exceptions). The tools vary in their level of support for these activities. Most of the tools provide a text-oriented view of requirement management. A few of the tools take a model-oriented view of requirement management. Another emerging approach is design capture (rather than documents describing model or function design) from all perspectives and requirements, through the various implementation alternatives. The term traceability is used to denote a relationship between a requirement and any other element of the system engineering process such as a design component or specification document. Many of the tools support traceability links between requirements and design elements, allocation of requirements to design elements and traceability between specification documents. Organizational capabilities of the tools include grouping of functional requirements and assignment of keywords and attributes to requirements and links to facilitate searching for sets of requirements. Other characteristics available in requirement management tools include generation of customized reports and interfacing with other system engineering and software engineering tools. Many of the tools also provide a graphic, multiwindowed user interface. 53/162

54 4.2 Requirements for an SRS tool Software Requirements Specification is a crucial system/software engineering activity that affects the ability of an organization to produce cost-effective technical products. Software requirement tools are therefore frequently used to make software requirement management easier. However, selection of the most suitable tool is not so simple. Software requirement management tools depend upon the user and his circumstances as well as upon the requirement management process. This section describes the requirements needed for a software requirement management tool. 1. Input document enrichment/analysis - Uses existing document information (such as glossary, index, etc.), aids the user in requirement analysis, identification of requirements, etc. 2. Input document change/comparison analysis - Compares/contrasts two different documents. 3. Quality and consistency checking (spell, data dictionary) - Supports document quality and consistency, spell checking, acronym tables, etc. 4. Saving and reloading - Saves the document information, schemas and diagrams, and reloads them, making changes, and saving again. 5. Requirement identification - Identifies or creates requirements. 6. Requirement classification - Classifies/categorizes requirements during identification. (for example classifying requirements as functional or nonfunctional etc) 7. Requirements derivation (req. to req, req. to analysis/text) - Derives/creates additional requirements and links them, e.g. requirement to requirement, or requirement to text (representing trade studies). 8. Traceability analysis Traces (1) Software Requirements Specifications requirements to system requirements in concept documentation, (2) software 54/162

55 design descriptions to software requirements specifications and software requirements specifications to software design descriptions. 9. Graphic capture requirement structure - Can the tool graphically capture system implementation (such as architecture, functional decomposition, etc.) and display them graphically so that requirements can be linked to them. 10. Identify inconsistencies - The tool should allow the user to identify inconsistencies such as requirements and diagram inconsistencies. The tool also should verify the relationship between the diagrams and display an appropriate error message in case of validation mistakes. 11. Standard specification output - The requirement management tool should output documentation in various standard formats (IEEE-830, etc.). 12. Presentation output - Once the information is loaded, the requirement management tool should support the generation of presentation quality charts and graphic elements such as case diagram, context diagram, data dictionary, data flow diagram, and class diagram. 13. Custom output features (user definable tables, figures) - The tool should support the output of documents in final form, including user definable tables, diagrams, etc. 14. WYSIWYG previewing of finished output - The tool should allow the user to view the document on-screen in final format. 15. Import of existing data from various standard file formats - The tool enables the import of existing data (such as a ASCII text file) to create structures within the tool without having to re-enter the information. 16. Multiple platforms/operating systems - The tool should run on different platforms and different operating systems. 17. Exchange of information between same-tool different installations - Since the tool will be used at different sites and on different projects, it should interchange information between different tool installations or databases. 55/162

56 18. Simultaneous update of open views - The tool allows for multiple windows/views into the tool, and changes in one view are automatically reflected in all other views. 19. Online help - The tool should include detailed online user manuals. 20. Defining new standard/schema Enables the user to define new schema/standard from which the document was generated. 21. Supports aspects diagram Enables the programmer to write and draw aspects and relationships between them. 56/162

57 4.3 SRS tools This section presents a tool survey and tool comparison. The tools presented and compared are recognized for a number of years as requirement tools. This section also checks and verifies which of the requirements listed in paragraph 4.2 are fulfilled and which are not Smart draw Smart Draw is a software tool, for creating business charts and diagrams [34], Smart Draw offers complete business graphics solutions, integrated sets of symbols, templates, instructions, and tutorials, including: Business Process Management, Software Design, Network Design. Smart draw has a simple drag-and-drop drawing interface that lets you draw any of the thousands of pre-defined shapes with one click. Smart draw also integrates with other programs, meaning that embedding SmartDraw drawings into Microsoft Word, Excel, PowerPoint - and any other client program - is easily accomplished. Smart draw also enables selection from more than 50,000 ready-made symbols, templates, and sample drawings, by browsing for symbols in the SmartDraw Explorer or searching for them by name and keyword, SmartDraw also enables the user to customize the built-in symbols by creating his own libraries and templates. SmartDraw create flow charts, block diagrams, data flow diagrams,decision trees, organizational charts, network diagrams, floor plans,process flow diagrams, process flow diagrams, schematics and more. 57/162

58 4.3.2 RDD-100 RDD-100 is a Requirements Driven Development (RDD) software suite that uses several mechanisms to aid the user in analyzing and identifying requirements [41]. These include a parser tool that can be defined and developed to help the user identify single or compound requirements. RD-100 allows the user to categorize requirements in a specific manner; the rules for this categorization can be captured and automated. RDD-100 captures and traces requirements using its Element Relationship Attribute (ERA) repository, where each source document, and text for each requirement is stored as a separate element. The tool can extract requirements from ASCII documents. RD-100 also provides the user with the capability to interactively manipulate and input data through a variety of diagrams including functional flow diagrams and data flow diagrams. 58/162

59 4.3.3 Analyst Pro Analyst Pro is a tool for requirement management, tracing and analysis [36]. Analyst Pro uses a requirement management methodology that covers the entire life cycle including, from the initial requirement-gathering phase through the separation phase where requirements and non-requirements are set apart. Analyst Pro utilizes a configuration management methodology that enables the development staff to analyze the effect of change on requirements and component assets. Analyst Pro incorporates the following features: Importing requirements - allows users to import requirements from existing documents from various formats (doc, html and text). Requirements sharing - allows users to share and trace requirements across projects. Requirements change management - automatically records and lists any changes in the required project, date of change, and who made the changes. Requirements assignment - Users can assign requirements to team members and track their status. Requirements Graphs - Users can create pie and bar graphs with a number of requirements versus attributes. The attributes include priority, version, status and source. The framework provided by Analyst Pro includes requirement definition, software design, software test, and project management. Analyst Pro classifies requirements using a standard approach that applies uniformly to all projects. Requirements are linked in a way that allows traceability between requirements (parent / child) and between requirements and delivered software components. This assures both that all business needs are met and that software developers stay focused on real user needs. With these structures in 59/162

60 place, Analyst Pro can generate complete system documentation in many different formats AxiomSys AxiomSys builds a detailed structured analysis model of the system [37]. AxiomSys provides mechanisms to trace how and where each requirement is fulfilled, and verifies the entire model for consistency and logical integrity. AxiomSys provides the capability to cross-reference any type of information to the processes, modules and data items in the model. If the trace items are requirements, the cross-referencing can then define the processes that implement a requirement, and conversely, the requirements satisfied by a process. AxiomSys provides automated documentation ability as well as providing report templates. AxiomSys provides the capability to cross-reference any type of information to the processes, modules and data items in the model. These trace items can be system requirements, test plans, schedule milestones or other information. If the trace items are requirements, the cross-referencing can then define the processes that implement a requirement and conversely, the requirements satisfied by a process. If the trace items are test plans, the cross-referencing can then define the processes that are tested within a given plan and conversely, the test plans that test a given process. 60/162

61 4.3.5 EasyRM EasyRM requirement manager is a CASE tool covering the initial stages of the software project development, including glossary, requirement and reference documentation management [38]. The EasyRM Requirement Manager provides users with the following facilities: Creation, description, modification and progress tracking of project requirements. Classification of requirements, including the ability to have several independent classifications of the same requirement set. Specification of relationships between requirements, including requirement decompositions, dependencies, correlations, conflicts, etc. Maintenance of semantic links from requirements to glossary terms and phrases used in requirement specifications. Maintenance of traceability links from requirements to information sources where these requirements have originated. 61/162

62 4.3.6 IRqA IRqA is a requirement-engineering tool designed specifically to assist in early stages of the software development process. IRqA supply requirements specification, analysis and management. Features include a powerful and innovative mechanism to classify requirements [39]. Requirements can then be classified according to criteria such as priority, type, status, or any other criteria, using management facets. The tool supports two kinds of models, Object -Oriented models, or Entity- Relationship models. IRqA enables the users to capture and manage requirements, analyze them in relation with the business domain in which they are categorized, and represent the system being built by means of clear and expressive techniques, understandable directly by the end user. In addition, IRqA helps to manage the requirements and to trace them through the subsequent activities and stages in the system development. IRqA also adds graphical functions for supporting the specification organization for large and complex projects, guaranteeing the specification quality. IRqA is requirements engineering oriented (vs Requirements Management only) and supports the following: Requirements capture. Requirements analysis. System specification building. Specification validation (specification vs requirements). Acceptance tests management. Requirements organization & classification. Requirements management. IRqA also supports full traceability from one element to another one of any type (i.e: requirement, concept, service, test scenario, etc). 62/162

63 4.3.7 RequisitePro RequisitePro is a requirement management tool designed for multi-user environments. It features integration of Microsoft Word and a requirements database [40]. Software project teams can gather, enter and manage requirements "in situ" (within the documents) or in a database. An automated traceability feature tracks requirements and changes through implementation and testing. Related requirements can be linked together, so that as changes occur to one requirement, users can easily see their impact on other related requirements. RequisitePro includes templates to simplify production of requirement documents. RequisitePro supports a choice of databases (Oracle, Microsoft SQL Server, and Microsoft Access), which allow users to organize, prioritize, and trace relationships between requirements. RequisitePro offers the power of a database and Microsoft Word. Its robust architecture maintains live requirements documents that are dynamically linked to a database for powerful sort and query capabilities. This allows the user to easily organize and prioritize his requirements, to trace relationships between them, and track changes that affect them. Robust traceability features visually indicate how changes affect the project, thereby enabling performance of real-time impact analysis and allowing informed decisions for scope management or resource allocation to be made. As a result, requirement change can be managed more effectively, and the project is less likely to spiral off course. RequisitePro captures the change history for each requirement, thereby providing a paper audit of the evolution of project requirements. 63/162

64 4.3.8 DOORS DOORS [42] (Dynamic Object Oriented Requirements System) is an Information Management and Traceability (IMT) tool. Requirements are handled within DOORS as discrete objects. Each requirement can be tagged with an unlimited number of attributes allowing easy selection of subsets of requirements for specialist tasks. DOORS includes an on-line change proposal and review system that lets users submit proposed changes to requirements, including a justification. DOORS offers unlimited links between all objects in a project for full multi-level traceability. Impact and traceability reports as well as reports identifying missing links are all available across all levels or phases of a project life cycle. Verification matrices can be produced directly or output in any of the supported formats including RTF for MS-Word. The DOORS Extension Language (DXL) is a high level C-like language that provides access to virtually all DOORS functions for user extensions and customization. 64/162

65 The table below lists all the above-mentioned management tools and the relationships between the entities previously defined in this section, the first column in the table specifies the requirement number as defined in paragraph 4.2 and the row defines the above tools. Each entry in the table can be one of the following: Full the tool fully meets the corresponding requirement. Part the tool partially meets the corresponding requirement. None - the tool does not meet the corresponding requirement. Tools Requir ement Smart Draw RDD-100 Analyst Pro AxiomSys EasyRM IRqA Requisite Pro DOORS 1 Part Part Part Full Full Full Full Full 2 Part Full None Part Part Full Full Full 3 Full Full Full Full Full Full Full Full 4 Full Part Part Part Full Part Part Full 5 Full Part Part Full Full Full Full Full 6 Full Full Part Full Full Full Full Full 7 Part Part None Part Full Full Full Full 8 Full Full Full Full Full Full Full Full 9 Full Full Full Full Full Full Full Full 10 Full Full Full Full Full Full Full Full 11 Full Full Full Full Full Full Part Full 12 Full Full Full Full Full Full Part Full 13 Part Part None Part Part Full Full Part 65/162

66 14 Part Part Part Part Full Full Full Full 15 Full Part Full Full Full Full Full Full 16 Full Full None Full Full Full Full Full 17 Full Full None Part Full Full Full Full 18 Part Part None Part Part Part Full Full 19 Full Full Full Full Full Full Full Full 20 None None None None None None None None 21 None None None None None None None None Table 2 Comparison of Related tools 66/162

67 5. DorsGen DorsGen is an easy-to-use software tool for automatically generating SRS documents and diagrams. Drawing a diagram with DorsGen is fast and easy, and requires no artistic talent. The user simply drags and drops ready-made graphic elements to create professional-looking diagrams. The diagram will generate an SRS document. Requirement management is essential for improving the software development process. The better the communication and management of the requirements, the more likely will the correct problem be identified, and the right solution delivered, DorsGen helps facilitate that process. The demands and pressures of the real world facing system developers involved in building today's complex systems inspired the DorsGen design, which grew out of the frustrations created by many CASE tools, DorsGen provides both high performance and an extremely well designed user interface. The result is a tool that is easier to learn and more straightforward to use than the CASE tools of the past. The DorsGen user interface provides an abundance of innovative convenience features which save time and allow the user to concentrate on the real task of system analysis. The DorsGen tool includes four main functions: Writing an SRS document Drawing SRS diagrams Validating document content Creating new standards 67/162

68 Figure 3: The DorsGen tool Writing an SRS document - DorsGen supports a variety of standards for writing an SRS document, such as IEEE-830 etc., After selecting one of those given standards, the tool loads a standard schema and the appropriate graphic window is displayed. Each window includes relevant questions and default data suitable to the chosen standard, and the user should add/delete/modify them. With a click of the mouse, the schema is generated to a MS-Word document. The figure below displays the IEEE-830 schema and example of its default data. Figure 4: IEEE-830 schema 68/162

69 The DorsGen tool also enables the user to add a functional/non-functional requirement through the tool and generate those requirements to an MS-WORD document. In this way the user can easily add/delete/modify the software/system requirements. The figures below show the schema of writing functional/non-functional requirements (Figure 5), and the generated MS-WORD document (Figure 6). Figure 5: Defining requirements window 69/162

70 Figure 6: Document result 70/162

71 Drawing SRS diagrams - DorsGen provides easy to use, interactive graphic editors for the creation of a data dictionary, use case diagrams, context diagrams, data flow diagrams, and class diagrams (at this stage the DorsTool does not support drawing a State chart but it may support it in the future). Hyperlinks to all associated information simplify the creation of correct syntax, and balanced and consistent diagrams. DorsGen produces intelligent diagrams far more effectively than ordinary diagrams, and provides information at a glance on the completeness. The diagram structure is defined and designed after extensive research of existing tools in the market and an understanding of the needs of companies and developers. This section describes the diagram structures and design decisions which help developers to write SRS documents more easily and clearly, and without mistakes and inconsistencies. The DorsGen diagrams (case diagram, context diagram, data flow diagram and class diagram) are closely inter-linked between the diagrams, and between the diagrams and the SRS schema. Drawing the SRS diagram affects the SRS schema, and updating the SRS schema influences the SRS diagrams. For example, writing a new functional requirement for the IEEE-830 schema will generate a new process to the DFD diagram. Those tight relationships make the writing process easier and minimize the mistakes. The tool improves the writing process and the same information cannot be written twice; once the information is written, all other diagrams will inherit it and be updated accordingly. The following paragraphs describe the use case diagram, context diagram, data dictionary, data flow diagram and class diagram, and the design decision, which is considered? and finally implemented. Use case diagram The DorsGen use case diagram includes two kinds of diagram: abstract diagram and extended diagram - the former summarizes all the use cases of the system, and the latter describes the extension of each summary 71/162

72 use case. Each use case is tagged with one of three levels: summary, elementary task or sub-functions. A summary use case can be extended to a few elementary task use cases and an elementary task use case can also be extended to a few sub-function use cases. All summarized use cases are displayed in the abstract diagram and the elementary task and sub-function are displayed in the extended diagram. The extended diagram supports <<include>> and <<exclude>> links, which can be drawn between elementary tasks, and between elementary tasks and subfunctions. Drawing a use case diagram has an impact on the context diagram, DFD diagram and document schema. It influences the context diagram by setting the use case actors as the external entity in the context diagram, it influences the DFD diagram by setting the summary use case as the DFD0 in the DFD diagram, and it influences the document schema by updating the functionality paragraph of the generated document. Appendix 8 describes one of the generated use case templates. As the use case is utilized for object oriented design, and there is a need to define a mechanism which outlines the designed objects through the use case diagram, a major feature of the DorsGen is location and display of all objects defined in the use case scenario. The screens below illustrate the use case diagrams and their generated diagrams. Figure 7 displays a use-case definition named Patient-management, and the Patient-Management scenarios are defined in the description section. The defined scenario also includes objects named <<Patient>>, so the patient object will be displayed in the objects diagram. (Figure 8 shows the system objects diagram, which is a generated result of the use-case) 72/162

73 Figure 7: Use-case definition Figure 8: system object diagram 73/162

74 The next two screens show the use-case diagrams and their results. The diagram in Figure 9 displays the abstract diagram drawn by the user, and the diagram in Figure 10 is the extended diagram of the Patient Management use case. Figure 9: Abstract diagram Figure 10: One of the extended diagrams 74/162

75 Figure 11 displays the Context-Diagram and Figure 12 displays the DFD diagram generated from the drawn use-case. Figure 13 shows the use case result, which is part of the SRS MS-WORD document. Figure 11: Context diagram Figure 12: DFD0 diagram 75/162

76 Figure 13: Use-case document result Context diagram The DorsGen context diagram includes an external entity that Get/Set data from/to the system. Each external entity represents an actor in the use case diagram. Adding an external entity to this diagram generates a new actor in the use case diagram and vise-versa, and also assigns the actor and its definition to the generated document. Data dictionary The data dictionary may contain information about the data structure, data and data store. The data structure uses the BNF algebraic notations [12,31,32]. All defined data stores are loaded to the DFD diagram and displayed there. Appendix 4 describes the BNF notation implemented in the DorsGen tool. Figure 14 shows the types table and its default values, for example the integer type in an expression of [Digit+]. 76/162

77 Figure 14: Default types In the sample below (Figure 15) Doctor is added, in the data type Profession category. Figure 15: Data dictionary table 77/162

78 Figure 16 shows a new data store called Hospital Staff which includes two data types: doctor and nurse. Figure 16: Data store table 78/162

79 Data flow diagram The DorsGen data flow diagram entities are processes and data stores. The DorsGen enables drawing extended DFDs as needed (DFD0,DFD1 ). The DorsGen supports the methodology that data flow between processes can be made only through data stores and not explicitly from one process to another. The DorsGen also verifes the diagram consistency, ascertains each diagram content, and validates the relationships between DFDs and other elements. The DFD also details the linkage to the functional paragraph in the generated document. Figure 17 illustrates one of the DFD levels drawn by the DorsGen tool. Figure 17:DFD diagram Class diagram The class diagram includes two types of entity: class and aspects. Each class/aspect entity includes attributes and methods. The DorsGen supports the UML notation used to draw this diagram. Class diagrams can be used to describe a static structure of the system, and define the static relationships between these objects. DorsGen enables expression of aspect classes and relationships between them, in order to satisfy 79/162

80 these requirements. The DorsGen introduces the following two new stereotypes [22]: <<aspect>> - An <<aspect>> is a class that represents an abstraction of crosscutting concerns and is used to model units of crosscutting concerns. Each aspect has to associate with a class or other aspects. <<crosscut>> - The crosscut stereotype will be used to model crosscutting relationships where the aspect code crosscuts the core functional components. A <<crosscut>> association is only valid between aspects and classes. The DorsGen also supports various examples of non-functional aspects, such as those aspects written in AspectJ notation, and can be linked and executed to the AspectJ application. Appendix 6 includes a sample code for tracing aspects, and appendix 7 includes a bounded-buffer aspect diagram example generated by the DorsGen tool. In future research in paragraph 7 there is a description of the notation that the DorsGen tool will support for full notation of aspect diagrams. Figure 18:class and aspect diagram 80/162

81 Validating document content DorsGen has the capability to assure consistency of the requirements. DorsGen has the most complete verification, validation and consistency checking of any diagrams and data. A formal inspection of the requirements document is conducted during verification and validation. Verification entails examination as and when requirements are generated, while validation is conducted on the entire specification document. Informal preliminary reviews during requirements elicitation are also useful. The following provides activities commonly conducted during verification and validation: The SRS correctly describes the intended system behaviors and characteristics. The requirements are complete and of high quality. All views of the requirements are consistent. The requirements provide an adequate basis to proceed with product design, construction and testing. Appendix 3 describes some of the validation rules that the DorsGen performs. Figure 19: Verification results 81/162

82 Creating new standard One major feature that DorsGen includes is the ability of each organization to define and create its own schema (well known standard or internal standard) from which the generated document is built. The DorsGen enables the creation of any kind of schema for any kind of standard, such as system requirement or testing document etc., but its main goal is to create an SRS standard. After creating a new schema, a new icon will be inserted into the toolbar. Pressing the icon will load the appropriate schema and graphics windows, and the generated SRS document skeleton will conform to the selected schema. DorsGen belongs to a new generation of requirement engineering tools. The emphasis is not only on requirement management but also on requirement analysis, project organization and description of high-level functions, which comprise the system being constructed. As a result, DorsGen streamlines the software requirement management process to increase efficiency and effectiveness in system development by using state-of-the-art requirement engineering methodologies and techniques. The DorsGen has been carefully designed to make future extensions (i.e. writing additional components) as easy as possible. Therefore, DorsGen is much more customizable to individual project needs than most conventional CASE tools. The separation of an entire DorsGen into small manageable components has enabled extensive testing of these components, thus improving the overall product reliability. Although the tools described in section 4 are powerful products, they are better suited for technical experts. It can be overwhelming for the average user to draw a DFD or class diagram without learning a complex program. DorsGen however, provides a simple drawing but powerful enough for building an SRS document. The two screens below display the creation of new standard processes: standard structure definition (Figure 20), and one of the paragraph definitions (Figure 21). Figure 22 shows the new standard result. 82/162

83 Figure 20: Defining the new schema structure Figure 21: One of the paragraph types 83/162

84 Figure 22: The new standard graphics result 5.1 Features supported by DorsGen This section checks which of the requirements described in section 4.2 are fulfilled by the DorsGen and which are not. 1. Input document enrichment/analysis DorsGen generates a unique ID number for each requirement as it is created, allowing the user to identify the requirement by its ID. If a requirement is deleted the ID is also deleted. 2. Input document change/comparison analysis DorsGen uses MS-Word, as its standard document export. All capabilities/features of MS-Word are available from DorsGen, thus tracking changes, and comparing and contrasting of documents can be configured to the needs of the user. DorsGen uses standard MS-Word processors for exporting documents. It can use FrameMaker's or Word's existing document comparison capabilities. 84/162

85 3. Quality and consistency checking (spell, data dictionary,) DorsGen outputs the SRS document into a MS-Word document. As such, users have access to all MS-Word features such as grammar, spelling, and other checkers. 4. Saving and reloading After writing the SRS document the DorsGen tool generates an MS-Word document which is built according to the chosen schema. These outputs can be saved, in an XML file which includes the entire database related to the document. The saved XML file also includes the schema from which the document is built so that the user can reload it, and all the relevant windows of this schema will loaded through the tool and displayed on the monitor with its content, for re-editing if necessary and regeneration. 5. Requirement identification DorsGen generates an MS-Word document so that requirements can be identified from Microsoft Word by simply selecting MS-Word type styles, and new requirements manually created. 6. Requirement classification One of the DorsGen options is the definition of the software requirement with the creation of a DFD. This option classifies the requirements according to the DFD levels (the DFD level from which the requirement capture organizes requirements). The DorsGen also displays the requirements as a tree and each level in the tree specifies the requirements that belong to that DFD level. 7. Requirements derivation (req. to req, req. to analysis/text) Not supported by the DorsGen tool, but it will be supported in the future. (How the DorsGen will support this feature is described in the Summary and Future Work n section Traceability analysis As described above, the DorsGen organizes the requirements by grouping them into DFD levels, so that the user can trace the requirements and is able to view the links between those requirements. 9. Graphically capture requirement structure DorsGen provides a rich editing environment, which will permit the usage of rich text, tables and 85/162

86 images to describe all types of requirement. However the user can choose to organize the requirements, such as functional decomposition. They can be graphically depicted from varying angles allowing the requirements to be graphically associated with that particular view of the system. 10. Identify inconsistencies DorsGen has a powerful report wizard, which allows easy selection of objects that do or do not satisfy certain conditions. The DorsGen, reports are designed to pinpoint inconsistencies based on logic queries. This report generator allows users to quickly identify inconsistencies. Identification of inconsistencies is also possible via graphic inspection or manual review of the individual requirements or system element if the user wishes. 11. Standard specification output Since a developer can define his own documentation structure, he can obtain the document in the standard format that he needs. The DorsGen also exports well-known standard templates, such as IEEE-830, which allows users to output the document in those standard specification formats. 12. Presentation output DorsGen supports generation of presentation quality diagrams as context diagrams, use case diagrams, DFD diagrams and class diagrams. 13. Custom output features (user definable tables, figures,..) DorsGen implements this capability through direct integration with Microsoft Word This integration allows users to make requirement changes directly within the DorsGen tool environment. Changes made in the DorsGen environment are automatically propagated to the related documents upon user request. This approach provides the best of breed solution for document production, and allows DorsGen to focus on providing value in the requirement management area. 14. WYSIWYG previewing of finished output DorsGen enables the user to view the document structure and content (preview results) at any working 86/162

87 stage. What you see is what you get, and since the documents are MS-Word based, users can always preview them before printing. 15. Import of existing data from various standard file formats - DorsGen imports and exports XML capability. 16. Exchange of information between same-tool different installations DorsGen imports an XML file format, which dynamically stores the database, and the DorsGen application structure according to this database, so that different installations are not influenced by the tool capabilities. 17. Multiple platforms/operating systems DorsGen runs on a PC platform using Microsoft operating systems: MS Windows 95, 98, NT 4.0, 2000, XP. 18. Simultaneous update of open views DorsGen database ensures that all windows are active. Changing information in one window updates all windows since all windows are looking at the same object. All requirement information in an open view is dynamically updated when a requirements document is saved or a requirement in the database is changed 19. Online help - DorsGen includes on-line user manuals, on-line help, a wizard to help new users get a quick start, and an on-line tutorial. 20. Defining new standard/schema DorsGen enables the user to define his own schema from which the SRS document is built. By selecting this schema, appropriate graphics will be loaded to the monitor, and the generated document will be created according the defined schema. The new schema is stored in an XML file, so that each time the user asks to open an existing standard, the schema of the chosen standard is loaded from the XML file.after the user? 21. Supporting aspects diagrams An Aspect diagram is well supported by modeling languages, like UML. Thus, as the DorsGen supports UML notation, it can be used in order to draw an aspect diagram. 87/162

88 The table below is extension of the table that described in section 4.3, which also compare the DorsGen capabilities. Tools Requir ement Smart Draw RDD-100 Analyst Pro AxiomSys EasyRM IRqA Requisite Pro DOORS DorsGen 1 Part Part Part Full Full Full Full Full Full 2 Part Full None Part Part Full Full Full Full 3 Full Full Full Full Full Full Full Full Full 4 Full Part Part Part Full Part Part Full Full 5 Full Part Part Full Full Full Full Full Full 6 Full Full Part Full Full Full Full Full Full 7 Part Part None Part Full Full Full Full None 8 Full Full Full Full Full Full Full Full Part 9 Full Full Full Full Full Full Full Full Full 10 Full Full Full Full Full Full Full Full Full 11 Full Full Full Full Full Full Part Full Full 12 Full Full Full Full Full Full Part Full Full 13 Part Part None Part Part Full Full Part Full 14 Part Part Part Part Full Full Full Full Full 15 Full Part Full Full Full Full Full Full Full 16 Full Full None Full Full Full Full Full Part 17 Full Full None Part Full Full Full Full Full 18 Part Part None Part Part Part Full Full Full 19 Full Full Full Full Full Full Full Full Full 20 None None None None None None None None Full 21 None None None None None None None None Full Table 3 Comparison between DorsGen and Related tools 88/162

89 5.2 DorsGen advantages There are a variety of software tools in the market, which enable different capabilities, and different features. This section describes the advantages of the DorsGen tool over the other tools, where the purpose of the project is to produce an SRS document and define the SRS requirements. Customization - The component-based architecture of DorsGen has been carefully designed to make future extensions (i.e. writing additional components) as easy as possible. Therefore, DorsGen is much more customizable to the individual project needs than most conventional CASE tools. Reliability - The separation of an entire DorsGen Suite into small, manageable components has allowed us to perform extensive testing of these components, thus improving the overall product reliability. Simplicity - Although the tools described in section 4.2 are powerful products, they are better suited for technical experts. They could be overwhelming to the average user who wants to draw a DFD or class diagram without having to learn a complex program. DorsGen creates a simple drawing, but which is powerful enough for building an SRS document. Better results - All other CASE tools attempt to solve all users problems, and therefore do not specialize. Tthe DorsGen, however, was specifically developed to make it easy to build an SRS document, therefore it is easier to use and understand, and the drawing results are better then with other tools. No errors -The DorsGen enables the user to draw easily diagrams, without mistakes, and according to diagram definitions. Standards - Unlike the DorsGen, none of the other tools generate an SRS document according to well-defined standards. 89/162

90 Automatic document generation - None of the tools described in section 4.2 automatically generates an MS-WORD document according to the drawn diagrams, or conversely, a diagram drawn according to user text. Schema creation - None of the tools described in section 4.2, can enable the creation of a new schema, from which the SRS document is produced. (Each organization can define its own schema/standard from which the document shall be generated). MS Word - The DorsGen generates a Microsoft Word document, which enables the user to re-edit the document if needed. Verification - The DorsGen verifies that the generated diagrams are valid and drawn according to standards. The tool also verifies the relationship between the Context Diagram, Use Case diagrams and the DFD (for verification rules see appendix 3). Updating - Drawing a single diagram will update all other diagram with its relevant data. For example drawing a use-case diagram (which includes actors and functions) will update the external entity (in context diagrams) with the actors from the use-case diagram, and the DFD diagram will update its DFD0 with the use-case functions. Focus - The DorsGen enables the SRS reader to concentrate and focus on the document contents and not to worry about document schema or diagram mistakes. Each organization can define its own schema from which the generated SRS document will be built. This feature ensures that the document schema conforms to the chosen standard, and that all documents in the organization comply with this standard format. This frees the organization the task of checking document schema. Appendix 10 describes an example of a generated document for the Object-Oriented-Design course in the Open University. The generated schema complies with the course definition. 90/162

91 6. Model for writing requirements using DorsGen After having motivated the need for a requirements engineering tool, now introduce the model for writing an SRS document, and its components. This represent a model that guides the requirements engineer, starting with generating a conceptual overview of the system, recognizing the problem at hand, eliciting requirements, and finally validating the requirements. Process modeling was crucial while devising the DorsGen tool (and its future work). Representing phases in a way that is lucid and intuitive was critical to aid the overall understanding of the process. Moreover, the process must be visually represented as a complete snapshot, enabling the requirements engineer to determine the context in which he/she is working. It is also imperative that the process model provides a representation of the progression of activities performed currently and in the future. To address these concerns associated with DorsGen, a software engineering modeling technique is employed. Separation of concerns, for process decomposition to identify the low-level activities, and high-level abstractions to enable the user to abstract back to the higher-level concepts to determine the context in which he/she is working. Separation of concerns is a concept that is at the core of software engineering, it refers to the ability to identify, decompose and manipulate those parts of a software process that are relevant to a particular concern (concept, goal, purpose, etc.). Every process and sub-process is decomposed to low-level activities or sub-processes, in an effort to make the overall process as lucid and coherent as possible. The requirements generation process is split into 4 components Conceptual Overview, Requirements Capturing, Requirements Analysis and Requirements Verification. Conceptual Overview Requirement Capturing Requirement Analysis Requirement Verification Figure 23: Writing Requirement model 91/162

92 6.1 Conceptual Overview Whenever a new project is contracted, it is important to document the initial interaction occurring between the two parties - the customer and the developer. Initial interaction result in a portrayal of the problem, as the customer perceives it. The development organization, in turn, can present to the customer, the infrastructure and expertise it possesses. The initial interaction culminates in a memo of understanding (a preliminary contract) between the customer and the development organization, outlining the problem and a brief description of the proposed solution. Moreover, it paves the way for further analysis. 6.2 Requirements Capturing Requirements capturing is the first phase that elicits information about the system, seeking the solution perspective. The activities conducted previously represent the problem space, for which the solution has to be devised. Requirements capturing culminates in the generation of software requirements of the proposed system. The requirements capturing process includes requirements elicitation meeting, local analysis and requirement evaluation. Requirements Elicitation Meeting Local Analysis Requirements Evaluation Requirements Capturing Figure 24: Requirements Capturing Requirements Elicitation Meeting - Once the problem has been captured and the needs have been elicited, the focus shifts on eliciting the solution. What functionality is the solution going to offer/possess? Requirements elicitation meetings are 92/162

93 conducted to elicit information from stakeholders. The primary objective is to identify and capture requirements as communicated by the customer and the users. Local Analysis - The local analysis process represents an innovative approach to the analysis of software requirements. The term local implies that activities defined within this phase are conducted as and when requirements are generated. Information associated with every requirement derived during local analysis is collectively analyzed in the requirements analysis process. For a reasonably large system, it is almost impossible to elicit requirements for the entire software in one sitting. Multiple meetings, involving a diverse set of stakeholders must be conducted to ensure complete coverage. During these meetings, requirements are generated and documented. Local analysis associates attributes to the appropriate requirement. The requirements engineer may select certain attributes while ignoring the others. The more information associated with each requirement, the more informed all stakeholders would be with respect to making decisions about the overall project. Requirements Evaluation - Requirements evaluation is the final sub-phase within the requirements capturing process. The evaluation phase is entered immediately after local analysis is conducted on the requirements generated in the preceding requirements elicitation meeting. Requirements evaluation is primarily conducted to verify the adherence of requirements to quality attributes. This helps uncover inconsistencies and redundancies. This may be done by the requirements engineer, using his/her own experience, or in consultation with the stakeholders and QA experts. The Requirements evaluation sub-phase also determines the need for an additional iteration through the entire requirements capturing process, or whether a transition to the requirements analysis phase can commence. At the completion of the requirements evaluation sub-phase, the requirement engineer, in consultation with the customer must determine if the requirements capturing process is complete. If the answer to this question is no, at least one more iteration through the requirements capturing phase is necessary. On the other hand, if all stakeholders 93/162

94 involved feel that all requirements have been captured meeting the correct intent, a transition may be made to the requirements analysis phase. 6.3 Requirements Analysis Requirements analysis is the process of analyzing customers and users needs to arrive at a definition of software requirements. Requirements analysis ensures that a correct software product is being built. Activities defined within the requirements analysis phase include risk analysis, cost & schedule analysis, market analysis and feasibility analysis. Requirements analysis also associates attributes, such as status, priority, effort and risk, for each requirement. It is especially important to understand the risks associated with implementing each requirement, including conflicts with other requirements, dependencies on external factors, and technical obstacles. Attributes associated with risk, priority and effort provide additional information about requirements when global analysis activities are conducted, ensuring that a more informed decision can be taken about the project. Requirements analysis is comprised of two sub-processes global analysis and requirements specification. Global analysis assesses the viability of the requirements from multiple perspectives, and the requirements specification process offers guidelines to document the requirements. Each of these processes is discussed in greater detail. Global Analysis Requirements Specification Requirements Analysis Figure 25:Requirements Analysis Global Analysis - The activities performed in the global analysis phase are similar to those conducted during local analysis. They differ, however, in scope. Local analysis is performed on requirements as and when they are generated just after 94/162

95 the requirements elicitation meetings, while global analysis activities are conducted on the complete set of requirements. The global analysis set of activities also represents a suite of decisions that must be taken, when requirements/features are generated. These decisions are listed after the analysis of various attributes. The information (and attributes) tabulated during local analysis is collectively analyzed to assess the overall progress of the project and whether the project makes sense. Requirements Specification- Once requirements have been captured and analyzed they must be organized and documented in the form of a document, referred to as a Software Requirements Specification. (SRS) 6.4 Requirements Verification The DorsGen Model offers Interwoven verification support to the requirements generation process. It includes activities intended to ensure that: The SRS correctly describes the intended system behaviors and characteristics The software requirements were correctly derived from the system requirements or other origins The requirements are complete and of high quality Requirements verification is comprised of two sub-processes requirement adherence and baseline requirements. Requirements Adherence B a s e l i n e Requirements (Configuration Control) Requirements Verification Figure 26:Requirements Verification 95/162

96 Requirements Adherence - Requirements adherence comprises of activities that ensure the adherence of requirements to expected conditions and standards. They include activities such as requirements traceability and formal technical reviews to seek mutual agreement about the overall SRS amongst customers and developers. The requirements adherence activities: Verify Quality Attributes - The importance of the requirements specification with respect to the overall software development lifecycle cannot be overemphasized enough. It is hence essential to verify all quality attributes of the overall document. It recommends that Independent quality analysts be involved to conduct this activity. A common mistake committed by customers and developers is that they focus on specifying functional or behavioral requirements, often not specifying explicitly, their expectations about how well the software product will work. These characteristics include how easy the product is to use, how quickly it executes, how reliable it is, and how well it behaves when unexpected scenarios arise [5]. Such characteristics, known as quality attributes, are referred to as the systems non-functional (or nonbehavioral) requirements, and must be specified, by the requirements engineer, in consultation with the customers and developers. Requirements Traceability - Requirements traceability entails the representation of links among requirements, needs, and other system elements. Requirements traceability is an important component of requirements verification, as it accounts for the fulfillment of all the needs established earlier for the system. Requirements traceability matrix links functional requirements to needs, and needs to problem elements. In this way, all the problem elements and needs can be guaranteed to be associated with one or multiple requirements. Baseline Requirements (Configuration Control) - Changes in requirements are inevitable these changes may occur during the design, coding or testing phase. The DorsGen model will significantly reduce the amount of rework and editions required subsequently in the software development lifecycle. The following guidelines can be employed while establishing the configuration control policy: 96/162

97 Ensure that all requirements are correctly numbered. For initiating a change, a formal change request form must be filled in and circulated by the stakeholder (including developers and testers) to all other stakeholders, outlining the change, and providing a detailed rationale for incorporating the change The newer version of the SRS must be circulated amongst all associated development teams and stakeholders. 97/162

98 7. Summary and future work Work on DorsGen model is motivated by the engineering needs for a requirement generator tool, which provides structural methodological approach to capturing requirements that meet the customer needs Although focused on requirements the DorsGen provides the structure that was lacking in other approaches. The following paragraph outlines some possibilities for future development and enhancement efforts for requirement generation. 7.1 Managing requirements with attributes All requirements have attributes whether we recognize them or not. These attributes are a rich source of management information that can help you plan, communicate and track your project s activities throughout the life-cycle. Each project has unique needs and should therefore select the attributes that are critical to its success. The following are sample of requirements attributes that the DorsGen will includes: Customer benefit - All requirements are not created equal. Ranking requirements by their relative importance to the end user opens a dialogue with customers, analysts and members of the development team. Effort- Clearly, some requirements or changes demand more time and resources than others. Estimating the number person-weeks or lines of code required, for example, is the best way to set expectations of what can or cannot be accomplished in a given time-frame. Development priority- Only after considering a requirement s relative customer benefit, and the effort required to implement it, can the team make feature tradeoffs under the twin constraints of a project s schedule and budget. Priority communicates to the entire organization which features will be done first, which features will be implemented if time permits, and which are postponed. Most rojects find that categorizing the 98/162

99 relative importance of requirements into high, medium and low, or, essential, desirable and optional is sufficient, although finer gradations are certainly possible. Status- Key decisions and progress should be tracked in one or more status fields. During definition of the project baseline, choices such as Proposed, Approved, and Incorporated are appropriate. As you move into development, In Progress, Implemented, and Validated could be used to track critical project milestones. Authors- The individuals (or teams) responsible for the requirement should be recorded in the requirements database. This might be the person responsible for entering the text or the person responsible for identifying the need. Responsible party- This is the product manager person, which is responsible for ensuring the requirement is satisfied. Rationale- Requirements exist for specific reasons. This field records an explanation or a reference to an explanation. For example, the reference might be to a page and line number of a product requirement specification, or to a minute marker on a video tape of an important customer interview. Date- The date a requirement was created or changed should be recorded to document its evolution. Version of requirement- As a requirement evolves, it is helpful to identify the version numbers (and history) of requirements changes. Relationships to other requirements- There are many relationships that can be maintained between requirements. For example, attribute fields can record: 1. The more abstract requirement from which this requirement emanated, 99/162

100 2. The more detailed requirement that emanated from this requirement, 3. A requirement of which this requirement is a subset. 4. Requirements that are subsets of this requirement. 5. A requirement that must be satisfied before this requirement is satisfied, etc. 100/162

101 7.2 Requirements traceability - ensuring quality and managing change DorsGen will supports requirements traceability, which is explicitly required in most manufacturers of all high reliability products and systems. Traceability is a link or definable relationship between two entities. Those who use requirements traceability find that it provides a level of project control and assured quality that is difficult to achieve by any other means. Benefits of requirements tracing - In its simplest terms, requirements tracing demonstrates that software does what it was supposed to do. The key benefits of this process include: Verification that all user needs are implemented and adequately tested. Verification that there are no extra system behaviors that cannot be traced to a user requirement. Understanding the impact of changing requirements. In addition to establishing document relationships to support traceability, you will need to employ some form of system to maintain links between individual items within the hierarchy. This could be done by embedding links and identifiers directly within the document, or by using a separate spreadsheet or database that manages the linkages outside the document. There are advantages and disadvantages to each of these approaches. A new class of requirement management tools automatically maintain traceability links. Ideally, this capability is integrated in the same tool that manages and manipulates the documents and their individual requirements. Traceability provides a methodical and controlled process for managing the changes that inevitably occur as an application is developed. Without tracing, every change requires that documents be reviewed on an ad hoc basis to see what, if any, elements of the project require updating. Because it is difficult to establish if all affected components have been identified, changes tend to decrease system reliability over time. 101/162

102 7.3 Requirements reporting - easing management reviews A requirements repository gives managers a powerful tool for tracking and reporting project status. Critical milestones are more easily identified. Schedule risks are better quantified. Priorities and ownership are kept visible. The DorsGen will provide answers to important questions, such as: 1. How many requirements do we have on this project? How many are high priority? 2. What percentages of the requirements are incorporated in the baseline? When and how will they be implemented? 3. Which requirements changed since the last customer review? Who is responsible for the changes? 4. What s the estimated cost impact of the proposed changes? High-level reports aid management reviews of product features. Requirements can be prioritized by customer need, difficulty and cost to implement, or by user safety considerations. These specialized reports help managers better allocate scarce resources by focusing attention on key project issues. The net result is that managers make better decisions and thereby improve the outcomes of their company s application development efforts. 102/162

103 7.4 Identify crosscutting In this section explain how to use DorsGen can support the identification of aspects in a set of requirements [12]. This operation can be made in three stages: Identify actions and entities - The tool takes the requirements, as written above, as input. Behaviors in requirements are identified by a set of keywords provided by the developer to the DorsGen tool. These behaviors are referred to as actions. Strictly speaking, any lexical string, including a non-functional requirement, state, etc. can be made a key-action if it was considered a candidate theme. Categorize actions into themes - Theme allows the individual design of different system features. In Object-orientation, not all the nouns in a requirements document are designed as objects or classes. Similarly, in Theme, not all actions are designed as separate features of the system: some actions are sub-behaviors of other actions. In this step, we set out to identify the features, or themes of the system, by identifying which actions are major-enough to be modeled separately (once we get to the point of modeling). For this, we use a DorsGen view called the action view. Identify crosscutting themes - DorsGen will use the major action view to help us determine which themes are base, and which are aspects. This view is made up only of the major actions from the previous action view. DorsGen focus in using this view is on the requirements that are shared by more than one theme. If a requirement is shared by two or more themes, we must decide which theme should provide that functionality. Shared requirements flag for us that we may have identified an aspect in our system, since they imply that two themes cannot operate without behaviorally relying on one another. 103/162

104 7.5 Aspect oriented requirements in the DorsGen Another approach presented here is the one from [11]. The authors suggest a notation on UML to define aspects at the early analysis and design steps of Aspect-oriented application development. DorsGen will support those notation introduces the following concepts: groups, aspects and pointcut relations. Group - A group represents a set of objects that are not necessary instances of the same class or super class. Thus the group notion allows the designer to reason about heterogeneous, but group-typed sets of objects [11]. Aspect-class - An aspect-class has regular attributes and methods, as a regular class, but it can contain methods that have particular semantics. As the authors propose, the extension is performed on well-defined implementation points, so that these points actually use aspect-services in order to integrate new concerns. The following stereotypes can be used: <<before>> / <<after>> / <<around>> / <<replace>> / <<role>> / aspectmethod ( contextual arguments ). Pointcut - A pointcut relation is intended to link some aspect-methods to some points of the base class. The association is stereotyped with <<pointcut>> and the roles have special semantics in order to indicate which methods of the client class are extended by which aspect method. Considering these approaches there seems to be a consensus in considering a NFR as crosscutting if it has an influence on more than one use case. However, the approach of [11] allows for a more precise identification and control of crosscutting NFRs by way of the templates defined in their approach. 104/162

105 References [1] F. Brooks, Essays on Software Engineering, 20th anniversary Edition, Addison- Wesley, 2nd Edition, [2] I. Sommerville, Software Engineering, Addison-Wesley Pub Co, 6th Edition, [3] R. Pressman, Software Engineering: A Practitioner's Approach, McGraw-Hill Science/Engineering/Math, 5th Edition, [4] S. Lauesen, Software Requirements: Styles and Techniques, Addison-Wesley Pub Co, [5] K. Wiegers, Software Requirements, Microsoft Press,2nd Edition, [6] C. Larman, Applying UML and patterns, Pearson Education,2nd Edition, [7] P. Muller, Instant UML, Wrox Press Inc, [8] S. Easterbrook, Experiences Using Lightweight Formal Methods for Requirements Modeling, IEEE Transactions of Software Engineering, January [9] K.Czarnecki, U.Eisenecker, Generative Programming, Methods, Tools, And Applications, May 2000, USA, Addison-Wesley. [10] I.Kiselev, Aspect-Oriented programming with AspectJ, 2003, SAMP pub., USA. [11] R. Pawlak, A UML Notation for Aspect Oriented Software Design, March 2002 Lab. Cedric-CNAM. [12] A. Porter, L. Votta, V. Basili, Comparing Detection Methods for Software Requirements Inspections: A Replicated Experiment, In IEEE Trans. On SW Eng, June 1995 (Vol. 21, No. 6), 105/162

106 [13] E. Kamsties, D. Berry, B. Paech, Detecting Ambiguities in Requirements Documents Using Inspections, In 1st Workshop on Inspection in Software Engineering, 2001, pp , [14] P. Sawyer, G. Kotonya, The SWEBOK Guide to the Software Engineering Body of Knowledge - Chapter 2 (software requirements), In a Project of the Software Engineering Coordinating Committee, IEEE Trial Version 1.00 May 2001, [15] F. Modugno, N. Leveson, J. Reese, K. Partridge, S. Sandys, Integrated Safety Analysis of Requirements Specification, In Requirements Engineering Journal, 1997, 2: [16] J. Mylopoulos, Exploring Alternatives During requirements Analysis, in IEEE Software, January/February 2001, [17] G. Sousa, I. Silva, J. Castro, Adapting the NFR Framework to Aspect- Oriented Requirements Engineering. In Federal University of Pernambuco (UFPE), /Papers/SousaEtAl.pdf. [18] A. Rashid, A. Moreira, J. Araujo, Early Aspects: a Model for Aspect-Oriented Requirements Engineering, In IEEE Joint Conference on Requirements Engineerin, Essen, Germany, September 2002, [19] A. Moreira, J. Araujo, I. Brito, Crosscutting Quality Attributes for Requirements Engineering, In 14th International Conference on Software Engineering and Knowledge Engineering (SKE 2002), ACM Press, Italy, July 2002, 106/162

107 [20] L. Bergmans, M. Aksit, Composing Crosscutting Concerns Using Composition Filters, In Communications of the ACM, Vol. 44, No. 10, October 2001, [21] E. Baniassad, S. Clarke, Theme: An Approach for Aspect-Oriented Analysis and Design, In International Conference on Software Engineering, 2004, [22] A. Aldawud, T. Elrad, A. Bader, UML Profile Aspect-Oriented Software Development, AOM Workshop at AOSD'03,2003, Internet sites [23] Methoda site [24] Methoda [25] DFD tutorial, [26] Modeling as part of the analysis and design, [27] UML, [28] IEEE standard association [29] View all IEEE computer society publications, [30] Software design guidelines, 107/162

108 [31] Backus-Naur form, [32] Backus-Naur syntax, [33] Visio, [34] Smart draw, [35] Rhapsody, [36] Analyst, [37] Structured technology group, [38] EasyRM, [39] Iraqa, [40] RequisitePro, [41] RDD, [42] Doors, 108/162

109 APPENDIX 1: IEEE 830 standard IEEE Recommended Practice for Software Requirements Specifications This American standard gives an outline to the contents and a detailed description of the contents of a good software requirements specification. The specification, unlike the military standard gives alternative layouts for the requirement specification section (section 3) of the software requirement specification document as well as the overall contents of the other sections. Outline of the Software Requirement Specification: 1 Introduction 1.1 Purpose of the Software Requirement Specification 1.2 Scope of the Product 1.3 Definitions, Acronyms and Abbreviations 1.4 References 1.5 Overview of the Rest of the Software Requirement Specification 2 General Description 2.1 Product Perspective 2.2 Product Functions 2.3 User Characteristics 2.4 General Constraints 2.5 Assumptions and Dependencies 3 Specific Requirements Appendices Index. 109/162

110 APPENDIX 2: MIL-STD-498 standard The United States military standard whose purpose is to "establish uniform requirements for software development and documentation." This standard merges DOD-STD-2167A and DOD-STD-7935A to define a set of activities and documentation suitable for the development of both weapon systems and Automated Information Systems. This standard includes Software Development Process, Software Engineering, Software Configuration Management, Software Product Evaluation, and Software Quality Assurance The specification has a rigid format for its contents, as detailed below: 1. SCOPE 2. REFERENCED DOCUMENTS 3. DEFINITIONS 4. GENERAL REQUIREMENTS 5. DETAILED REQUIREMENTS 5.1 Project planning and oversight 5.2 Establishing a software development environment 5.3 System requirements analysis 5.4 System design 5.5 Software requirements analysis 5.6 Software design 5.7 Software implementation and unit testing 5.8 Unit integration and testing 5.9 CSCI qualification testing 5.10 CSCI/HWCI integration and testing 5.11 System qualification testing 5.12 Preparing for software use 5.13 Preparing for software transition 110/162

111 5.14 Software configuration management 5.15 Software product evaluation 5.16 Software quality assurance 5.17 Corrective action 5.18 Joint technical and management reviews 5.19 Other activities 6. NOTES 111/162

112 APPENDIX 3: DFD verification rules This paragraph describes the DorsGen verification rules for each SRS document that includes DFD. There are several common rules that need to be followed when creating DFDs: All processes must have at least one data flow in and one data flow out. All processes should modify the incoming data, producing new forms of outgoing data. Each data store must be involved with at least one data flow. Each external entity (in the context diagram) must be involved with at least one data flow. External entities are objects outside the system, with which the system communicates. External entities are sources and destinations of the system's inputs and outputs. A data flow must be attached to at least one process. No duplicate external entities and data store. Data store to data store, external entity to external entity, or external entity to data store connection usually do not make sense. 112/162

113 APPENDIX 4: BNF rules BNF is an acronym for "Backus Naur Form", BNF is one of the most commonly used metasyntactic notations for specifying the syntax of programming languages, command sets, and the likes. The DorsGen use the BNF notations in order to define data structure in the data dictionary functionality, and use the following BNF rules: Terminator name of a rule is simply the name itself. - Elements separated by a bar (" ") are alternatives, e.g., "yes no" will accept yes or no. & - Elements separated by a ("&") are mandatory, e.g., "yes & no" will not accepted. () - Elements enclosed in parentheses are treated as a single element. Thus, "(elem (foo bar) elem)" allows the token sequences "elem foo elem" and "elem bar elem". * - The character "*" preceding an element indicates repetition. Default values are 0 and infinity so that "*" allows any number, including zero, + - The character "+" preceding an element indicates at least one repetition so that "+" allows any number, except zero.? - The character "?" preceding an element indicates that the elemet is optional. 113/162

114 APPENDIX 5: DorsGen example of tracing aspect The DorsGen tool provides the user a C code for several aspects, which can be compiled by the AspectJ compiler. This appendix describes one example of those aspects and it s called the tracing aspect. Writing a class that provides tracing functionality is easy: several functions, a boolean flag for turning tracing on and off, a choice for an output stream, maybe some code for formatting the output, these are all elements that Trace classes have been known to have. Trace classes may be highly sophisticated, too, if the task of tracing the execution of a program demands it. But developing the support for tracing is just one part of the effort of inserting tracing into a program, and, most likely, not the biggest part. The other part of the effort is calling the tracing functions at appropriate times. In large systems, this interaction with the tracing support can be overwhelming. Plus, tracing is one of those things that slows the system down, so these calls should often be pulled out of the system before the product is shipped. For these reasons, it is not unusual for developers to write ad-hoc scripting programs that rewrite the source code by inserting/deleting trace calls before and after the method bodies. AspectJ can be used for some of these tracing concerns in a less ad-hoc way. Tracing can be seen as a concern that crosscuts the entire system and as such is amenable to encapsulation in an aspect. In addition, it is fairly independent of what the system is doing. Therefore tracing is one of those kind of system aspects that can potentially be plugged in and unplugged without any side-effects to the basic functionality of the system. aspect TraceMyClasses { pointcut myclass(): within(*); pointcut myconstructor():execution(new(..)); pointcut mymethod(): myclass() && execution(* *(..)); before (): myconstructor() { Trace.traceEntry("" + thisjoinpointstaticpart.getsignature()); } 114/162

115 after(): myconstructor() { Trace.traceExit("" + thisjoinpointstaticpart.getsignature()); } before (): mymethod() { Trace.traceEntry("" + thisjoinpointstaticpart.getsignature()); } after(): mymethod() { Trace.traceExit("" + thisjoinpointstaticpart.getsignature()); } } This aspect performs the tracing calls at appropriate times. According to this aspect, tracing is performed at the entrance and exit of every method. 115/162

116 APPENDIX 6: Aspect diagram example The main synchronization requirement control access to the bounded buffer. For example we shall allow only the put methods to proceed when the buffer is empty state. Either put or get can be issued when the buffer is in partial state. We shall allow only get when the buffer is in full state. On the other hand, the main scheduling requirements may impose certain access requirements on the system. For example only one writer can access the system at a certain time, or more then one reader can access the system at a certain time. Synchronization constraints and scheduling specification are the main crosscutting requirements(aspects) that influence of the invoked methods based on the object s state. The synchronization and scheduling requirements can be modeled as aspects using the <<aspects>> stereotype. These requirements <<crosscut>> the main bounded buffer class. The <<aspect>> and buffer class can be statically weave using the profile of the DorsGen. DorsGen class diagram can be used to describe the static structure of the system (classes and aspects) and to define static relationship between these objects. Each class and aspect in the class diagram defines its own static structure including attributes, methods and interface. The line between classes denote association relationship. The figure bellow (which generated by the DorsGen tool) shows the object diagram for bounded-buffer design. 116/162

117 Figure 27: Bounded-buffer aspect diagram 117/162

118 APPENDIX 7: Use case template This appendix defines DorsGen generated use case structure. All the use cases no matter which level it is (summary, elementary task or sub function), has the following template. Use case name Scope Level Preconditions Success/Fail End Condition Primary,Secondary Actors Trigger DESCRIPTION EXTENSIONS SUB-VARIATIONS The name is the goal in short active verb phrase What system is being considered black box under design. One of: Summary, Elementary task, Sub function. What we expected. Successful/Failure completion. The names of the primary and secondary actors. The action upon the system starts the use case, may be time event. Description of the use case and its scenarios. Extensions of the scenario that described in the description section. Branching actions. 118/162

119 APPENDIX 8: DorGen Schemas The DorsGen include variants of default schema, each of those schema build according to a well-known standard, for instance IEEE-830, IEEE-830 for object oriented etc. The following table is the table of content of IEEE-830 for objectoriented standard. TABLE OF CONTENTS 1. Introduction Purpose Scope Definition And Abbreviation Reference Overview 1 2. Overall Description Perspective Function User Characteristics Constraints Assumption 2 3. Class Class definition Class Methods 3.2. User Interface Performance Requirements Constraint Attributes Other Requirements 2 119/162

120 APPENDIX 9: Generated document example The DorsGen tool can be used in the Object-Oriented-Design course (Open University course) the following is an example for a generated document for this course. The document was build according to IEEE-830 standard. TABLE OF CONTENTS 1. Introduction Purpose Scope Definition And Abbreviation Reference Overview 4 2. Overall Description Perspective Function Patient Management Introduction Process Handling Ordering Equipment Introduction Process Room Management Introduction Process Visitor Management Introduction Process User Characteristics Constraints Assumption 5 3. Functions Requirements Updating Patient Doc Introduction 6 120/162

121 Input Output Process Opening patient Doc Introduction Input Output Process Checking Request Introduction Input Output Process Closing Checking Introduction Input Output Process Ordering Request Introduction Input Output Process Ordering Introduction Input Output Process Put Patient To Room Introduction Input Output Process Manage Room Equipment Introduction Input Output Process Connect Patient to Visitor 9 121/162

122 Introduction Input Output Process Release visitor Introduction Input Output Process External Interface User interfaces Hardware interfaces Software interfaces Communication Interfaces Performance Requirements Constraint Attributes Reliability Availability Security Maintainability Portability Other Requirements Data Dictionary /162

123 APPENDIX 10: DorsGen user manual DorsGen is an easy-to-use software tool for automatically generating SRS documents and creating diagrams such as Context Diagrams, Use Case diagrams, Data Dictionary, DFD and Class Diagrams. Drawing these diagrams with DorsGen requires no artistic talent; users simply drag and drop ready-made graphic elements to create professional-looking diagrams. Figure 28: DorsGen main window The purpose of this appendix is to guide DorsGen users to work with the tool, and to demonstrate the power and simplicity of the DorsGen tool. The following guideline gives a step-by-step tool functionality. 123/162

124 The DorsGen includes three modes of work: 1. Working with defined standard In this working mode the DorsGen tool is used to generate SRS documentation and SRS diagrams, which are, built from one of a variety of standards supplied by DorsGen. 2. Creating new standard In this working mode a new standard is defined, which will become a part of the DorsGen tool. 3. Defining new aspects In this working mode a new aspect is defined which can compiled with an Aspect application. Working with a defined standard Create your SRS document by using one of the varieties of standards supplied by DorsGen. In order to generate an SRS document, which has one of these standard structures, perform the following eleven steps: 1. Open standard Open one of the given standards. 2. SRS detail After the standard is opened, define your software requirements. DorsGen provides easy navigation between the DorsGen windows so that the software requirement added is clearly visible without difficulty. 3. Draw context diagram If the chosen standard structure includes context diagrams, the tool enables easy and clear drawing, and verification of its content at the end. 4. Data dictionary - If the chosen standard structure includes a data dictionary, the tool enables an easy and unique system definition of data types and data-store. 124/162

125 5. Draw DFD If the chosen standard structure includes data flow diagrams the tool enables easy drawing of DFD diagrams and verification of their contents. 6. Draw use case diagrams If the chosen standard structure includes use case diagrams the tool enables drawing use case diagrams and verification of their contents. 7. Draw class diagram If the chosen standard structure includes class diagrams the tool enables drawing class diagrams and verification of their content. 8. Compiling the document After all diagrams are entered and all software requirements defined, you will need to use the compilation functionality to verify these diagrams and their relationships. The compilation verification result will be displayed. 9. View This functionality enables you to view the final SRS document result at any stage of work. 10. Save This functionality saves the document and creates all documents and diagrams. 11. Reopen This functionality opens an existing document previously created in order to edit it again. The following sections describe in more detail the above functionalities. 125/162

126 Open standard The DorsGen enables you to user to choose one of a variety of SRS standards defined by the DorsGen tool. One of these standards is IEEE-830. The IEEE-830 standard button in the DorsGen toolbar is shown in Figure 29. Figure 29: IEEE-830 Standard button in the toolbar After pressing the standard button, the tool uploads the appropriate graphics (SRS schema) windows showing the chosen standard. These windows enable you to easily write the software requirements without mistakes. Figure 30 shows the schema uploaded after choosing the IEEE-830 standard. The uploaded IEEE paragraph-tree (in the left side of the figure below) displays the IEEE-830 paragraphs (each standard includes its own paragraphtree). Figure 30 :IEEE-830 uploaded standard 126/162

127 SRS detail Open one of the standards to display the standard paragraph-tree, and add your software requirements by clicking on one of the paragraphs in the paragraph-tree. Each paragraph opens a window into which you should add your data. (Each of these windows also includes default data, which in most cases is written in a form common to all SRS documents, and should therefore not be edited. Figure 31 shows the purpose paragraph (one of the IEEE-830 paragraph). This is where you should edit the given default data. Figure 31 :Inserting data window 127/162

128 Draw context diagram This section describes the step that has to be performed in order to draw a context diagram. (Not all standards support context diagrams so this functionality is available only for those that support it). The context diagram button is shown in Figure 32. Figure 32: Context diagram button Press the context diagram button to display the context diagram window (Figure 33). Define the product name and its external actors. Figure 33: Context diagram window 128/162

129 Figure 34 displays how to insert a new actor to the context diagram, and Figure 35 shows the context diagram result after adding it. Each new actor should be named and described. Figure 34: Adding new actor Figure 35: Adding actor result 129/162

130 The context diagram information is linked to one of the paragraphs in the standard, so the context diagram information is automatically inserted to the appropriate paragraph in the SRS document, and vise versa; by adding information to a paragraph it is automatically included in the context diagram. In the case of the IEEE-830 the context diagram is linked to the paragraph named Perspective so the data inserted into the context diagram (product name and actors) is also inserted into the Perspective window. This is shown in Figure 36. Note adding an actor via this window only adds the actor to the Use case diagram. The association between the actor and the functionality is not included. Figure 36: Context diagram paragraph 130/162

131 Data dictionary The DorsGen enables you to define your system data dictionary (In the case that the chosen standard supports the data dictionary functionality), The data dictionary button is shown in Figure 37. Figure 37: Data dictionary button Press the data dictionary button to open a data dictionary window (as shown in Figure 38). The data dictionary comprises three parts: 1. Type definition defines a new type by using BNF rules (those types inserted to the types-table). 2. Data Name defines new data, whose type is taken from the types that exist in the types-table (new data inserted to the data-table). 3. Data store defines a new data store, each of which is created from a list of data taken from the data table. Figure 38: Data dictionary window 131/162

132 In order to define a new type, press on the data type button and a types-table will open. Each type in this table can be: Noun well defined type. Expression expression, using BNF rules, as described in Appendix 4. Figure 39 shows the types-table and its default values, for example the integer type description is an expression [Digit+]. Figure 39: Default types 132/162

133 You can also define your own type; each new type should include its name and its type (the type can be a noun or expression). Figure 40 displays an example of adding a new type called Profession whose type description is an expression [Letter+]. Figure 40: Data type table After defining the system types the next stage is to define all the data included in the SRS document. This step is accomplished by adding new data to the data dictionary table, where each item includes its description and its type, taken from the types-table. 133/162

134 Figure 41 shows an example of adding new data called Doctor whose data type is Profession. Figure 41: Data dictionary table 134/162

135 In order to add a new data store to the document, press on the data store button (shown in Figure 41), and a data store window will be opened, Add a new data store defined by its name, description and a list of data (from the data-list), Figure 42 shows a new data store called Hospital Staff which includes two data types: doctor and nurse. Figure 42: Data store table 135/162

136 Draw DFD In order to open a DFD diagram press on the data flow diagram button and the DFD window will be opened (this option is available only in the case that the chosen standard structure includes DFD) The DFD button is shown in Figure 43. Figure 43: DFD button After pressing in the DFD button a DFD window will open (window that defines the DFD0 level) Figure 44: DFD0 window 136/162

137 In the DFD0 window, add your DFD0 process, each process defined by its name, description and its process. (You can edit the process information by double clicking on the process and the window, which includes the process information, will be displayed). Figure 45 shows an example of adding a new process named P.1. Figure 45: Adding new process in DFD0 137/162

138 The tool also enables you to add new data stores to the diagram. You can choose one of the data stores previously defined in the data-store table. You can also add a new data store (that does not exist in the data-store table and this new data store will be inserted automatically to the data store table described in the previous paragraph) Figure 46 describes how to add a new data store to the DFD diagram Figure 46: Adding new data store 138/162

139 The DFD diagram also enables the user to add a link between the DFD components (process or data store), each link is defined by a name and the two components that need to be linked. Figure 47 and Figure 48 respectively show how to add a new data flow between two-processes and the resulting link. Figure 47: Insert link Figure 48: DFD adding link result 139/162

140 The DFD diagram can also be linked to one of the paragraphs in the SRS document so that all the DFD information is inserted automatically to this section and vice-versa. For example, the DFD information in the IEEE-830 is linked to the requirement section. You can add a new requirement and its description, where each requirement name is translated into a process in the DFD diagram. In the DFD diagram each process can have inputs, where each of the written inputs are translated to arrow in the DFD diagram. Figure 49 and Figure 50 respectively show how the DFD0 data is inserted to the requirement paragraph in the IEEE-830 standard, Figure 49 shows the Patient Management requirement paragraph plus its description and inputs (Id, First Name, Last Name) and Figure 50 shows the resulting DFD diagram. Figure 49: Requirement paragraph 140/162

141 Figure 50: Generated DFD result The DFD diagram also enables you to add new DFD layers (DFD1.. DFDn ) for each process. In order to create DFDn+1 for one of the processes in DFDn, click on the process (in the process tree in the left side of the window) and a new DFD diagram will open where you can draw its DFDn+1. Figure 51 shows the creation of DFD1 to P.1. Process. Figure 51: Creating DFD1 141/162

142 As described above, DFD can also be linked to the requirement section (in IEEE-830) standard, so that the new DFDn is also inserted into the requirement section, and vice versa; by adding DFDn into the requirement section a DFDn diagram will be added to the DFD diagram. Figure 52: DFDn in the requirement paragraph The DorsGen tool also enables you to verify its DFD diagram by pressing the Verify button. Figure 53: DFD verify button 142/162

143 The verify button verifies all the DFDs layers and its data store relationship, and displays the result (the DFD verification rules are described in appendix 3). Figure 54 shows the DFD verification results. Figure 54: DFD verification results 143/162

144 Draw Use Case diagram In order to draw a use case diagram press the Use case button (this button is available only in the case that the chosen standard includes Use Case diagrams), The use case diagram button is shown in Figure 55. Figure 55: Use case button After pressing the use case button an abstract use case diagram will be opened where you can add summarized use cases, and for each of those summarized use cases you can add an extended diagram. When drawing the extended diagram you can add <<include>> and <<exclude>> relations between the elementary tasks to themselves and between an elementary task and sub-functional use cases. The use case diagram also enables you to define its objects, by marking each object by << >>, in the description section. Figure 56 shows an abstract diagram, and Figure 57 shows one of the extended diagrams. Figure 58 shows how to define objects in a use case and Figure 59 displays an object result. 144/162

145 Figure 56: Abstract diagram Figure 57: Extend diagram 145/162

146 Figure 58: Defining objects Figure 59: Objects result 146/162

147 Draw class diagram In order to draw a class diagram press the class diagram button (this button is available only in the case where the chosen standard includes class diagrams), Figure 60 shows the class diagram button. Figure 60: Class diagram button After pressing the class diagram button the class diagram window will open, which enables you to add a new class and to draw the relationship between these classes (a relationship such as inheritance aggregation and etc.) Figure 61 shows the class diagram window. Figure 61: Class diagram window 147/162

148 You can add a new class to the class diagram; where each new class is defined by its name description, attributes and methods. Figure 62 shows how to add a new class to the diagram. Figure 62: Adding new class After adding classes you can add the relationship between these classes. Figure 63 shows how to add a new relationship between two classes. Figure 63: Adding relation between classes 148/162

149 Once you have drawn the class diagram you can verify the diagram by pressing the verification button, and the verification result will be displayed. Figure 64 and Figure 65 respectively show the verification button and the verification result. Figure 64: Class diagram verify Button Figure 65: Class diagram verification result 149/162

150 Compiling the document In order to generate the SRS document and its diagrams you have to compile the document. The compilation will create the SRS word document and diagrams. The compilation will also verify the SRS diagrams and the SRS content and verify the relationship between them. At the end of the compilation process the verification result will be displayed. Figure 66 and Figure 67 respectively show the compilation button and the compilation result. Figure 66: Compilation button Figure 67: Compilation result 150/162

151 View The view function enables you to view the SRS document result at any stage. Figure 68 and Figure 69 respectively show the view button and the view result. Figure 68: View button Figure 69: Document view result 151/162

152 Save You can save the current work at any stage and to open it again in the future. The save button is shown in Figure 70. Figure 70: Save button After pressing the save button you can navigate to the directory in which the DorsGen output will be saved. Figure 71 shows how to save the document with name Example. Figure 71: Directory navigation 152/162

153 The saving operation creates the following outputs: 1. Example.xml this file includes the entire document database. 2. Example.doc the SRS document in Microsoft WORD format. 3. Example.html the SRS document in Html format. 4. ExampleCd.html the context diagram figure. 5. ExampleUc.html the Use Case diagram figure. 6. ExampleDfd.html the DFDs figure. 7. ExampleDt.html the Data dictionary tables. 8. ExampleClsD.html the SRS class diagram. Figure 72: DorsGen generation output 153/162

154 Reopen A document that was saved previously can be reopened, in order to edit the SRS content again. The Open button is shown in Figure 73. Figure 73: open button In the open option choose the *.xml file, as this file includes the document database Figure 74 shows the result after reopening the *.xml file. Figure 74: Reopen result 154/162

155 Creating a new standard The DorsGen enable you to create your own standard from which an SRS document will generated. In order to create this new standard, press the Wizard button. The wizard button is shown in Figure 75. Figure 75: Wizard button After pressing the wizard button a wizard window will open. Figure 76 shows the wizard window. Figure 76: Wizard window 155/162

156 In the wizard window you will be asked to fill in the paragraph number in which the SRS schema is contained and their title. You should also indicate whether its schema includes a context diagram, DFD, class diagram or data dictionary. The DorsGen tool also gives you the option of choosing whether the diagrams will be embedded in the document or whether the document only includes a link to the drawn diagrams. Figure 77 shows an example of a new schema definition called Hospital. This schema is created from two main paragraphs, the first is called Overview which includes one sub paragraph and the second paragraph is called Functions which includes two sub-paragraphs. The following new standard also includes a context diagram, DFD and data dictionary. Figure 77: Defining the new schema structure After defining the schema structure for each paragraph the wizard displays a variety of paragraph types, and you can choose one of these types. In each chosen paragraph type enter windows titles and windows default data. 156/162

157 Figure 78 shows the Overview paragraph structure created from one subparagraph called Purpose and its structure OneEdit box. In this window you needs to enter the window title and the window default data. Figure 78: One of the paragraph types Figure 79 and Figure 80 respectively show the Functions paragraph structure created from two sub-paragraphs. In Figure 79 the sub-paragraph is a context diagram, which is linked to the Perspective paragraph, and in Figure 80 shows a DFD, which is linked to the Hospital Functionality paragraph. 157/162

158 Figure 79: Context diagram paragraph Figure 80: DFD window paragraph 158/162

159 After defining the new schema paragraph, a new button with the new schema name will added to the toolbar. Clicking on it will load the new schema window to the DorsGen. Figure 81 and Figure 82 respectively show the new button and the new schema after pressing it. Figure 81: The new standard added to toolbar Figure 82: The new standard graphics 159/162

160 Defining new aspects The DorsGen enable you to write new aspects, which can be linked to the AspectJ application. In order to add this new aspect press the aspect button shown in Figure 83. Figure 83: Defining aspect button After pressing the aspect button an aspect table will be opened. This table includes a variety of aspects already written which can be used. You can also add your own aspect. Figure 84: Aspect table 160/162