Sparx Systems Forum

Discussion => Suggestions and Requests => Topic started by: HydraKeven on November 15, 2007, 02:16:54 pm

Title: Software Engineering Standards - IEEE SRS SDD
Post by: HydraKeven on November 15, 2007, 02:16:54 pm
This is long but I hope it is not viewed as a rant.  I only wish to improve the process and software we all use.

I find the lack of discussion about Software Engineering Standards somewhat disturbing.  So in an effort to start specific interest in this area, I am starting this new subject.  Specifically, I am interested in the inclusion of some kind of modeling standard or template that can be used to structure EA in such a way that is follows something close to the IEEE SRS and SDD documentation standards.

To get some search items out of the way, I am listing some terms / acronyms here:

IEEE - Institute of Electrical and Electronics Engineers
SE - Software Engineering
SWEBOK - Software Engineering Body of Knowledge
SRS - Software Requirements Specification
SDD - Software Design Document

To be sure, there are many other terms / acronyms to define, such as SCMP, SPMP, SQAP, STD, SVV, and "Vision and Scope".  I resist mentioning others as these are the core documents and others are generally detailed subsections of these.

What I would like to do is concentrate on issues related to the SRS and SDD--what I consider the "meat and potatoes" for software analysis and design.  Also, while the IEEE standard does not specifically detail Object Oriented (OO) use for these documents, I will admittedly direct this discussion toward OO usage as it is the common practice.  My main concern is that we need documentation driven models that use visual representations for clarification, not visual models that hide documentation details as a secondary process.

Another area of concern I will add (just to stir the pot a little more) is "Peer Review".

While providing a tool for specifying UML diagrams, I find that these pictures are just one small part of effective software analysis and design.  My opinion is that the UML is not much of a "language" at all as it lacks a well developed grammar to support its use.  In other words, it does not specifically support a parser on its so called "language".  There are attempts by researchers to do such a thing as well as creating graph transformation on these diagrams to represent the different "views" on a UML model.

However, my main concern is the realization of well established documentation principles on the diagrams developed and presented via EA.  The diagrams should support a documentation standard that a shop adopts and not the other way around.  EA is fairly flexible in its use and contains features to support the creation of documentation, but I find that it lacks needed structure in several ways:

1. It is based on principles targeting design, not requirements.  As an example, the SRS defines "Use Cases" (UCs) as a requirement capturing mechanism--they express design requirements, not design.  In general, they are SRS Section 2 elements--Customer Requirements (or C-Reqs, if you like).  Therefore, they fall squarely in the domain of requirements and specifically C-Reqs.  UCs are a stepwise documentation of user interaction with a system (I use "user" loosely).  The UC diagrams should support the documentation and could be generated "automagically" to create a kind of "table of contents" to the actual use cases. However, EA has adopted a reversal of this process.  A UC object is a diagram object that supports its documentation like a "red-headed stepchild", as if the documentation of its steps were an afterthought instead of its primary purpose.  I blame this entirely on a misunderstanding of the UML Use Case diagram.

2. The models defy the distinctions between requirements (via SRS) and design (via SDD).  The SRS captures requirements.  The SDD realizes or implements a solution to every SRS requirement in its design (ok, "every" might be a little strong, but that is the intent).  However, we need a refinement of C-reqs before we can realize the design.  The SRS Section 3 contains Developer Requirements (or D-Reqs, if you like).  Here is where we describe a (sub)system's "Features" in developer terms.  Each "Feature" is some refinement of a Section 2 item--in general, a refinement of a UC.  So, these features refine the requirements of Section 2 by specifying finer detailed requirements.  Here we support "Sequence Diagrams" as a "Feature" element in the documentation.  EA defaults Sequence Diagrams as a UC element.  This tends to blur the distinction of C-Reqs and D-Reqs of the SRS.  While requirements are specified in the Requirements Model, they are generally a raw list.  Their relations can be specified within the model, but they should automatically be related through the relationship between UC and Feature (a C-Req to D-Req relationship).  In addition, we introduce the concept of class objects within a Feature via the Sequence Diagram and its related reqs.  Therefore, we have a Class Requirements Model that resembles a Class Model.  However, it differs in that it specified requirements for the class, not its design.  EA has no notion of a Class Requirements Model.  The Class Model supports requirements in that it assumes <<realization>> of the requirements, but not the specification for refinement of Feature requirements.  A Class Model is a Design Model in EA that, if use to specify reqs, blurs the distinction between the SRS requirements and SDD design.

3. It lack fine granularity of requirements association with
the lowest level objects in a model.  By this, I mean I can attach requirements to a Class object, but not to its attributes or methods.  Ideally, methods need requirements specification as a refinement of class/feature requirements.  Obviously, attributes need requirements related to range at the very least.  In addition, their is no notion of an instance of a class in the Class object.  Instances of a Class are a requirement specification as shown in a Sequence Diagram.  Again, I stress these as requirements and NOT design.  These SRS requirements drive the SDD design process.  Effectively, these requirement specifications can "automagically" create (and link to) the majority of design elements needed by the SDD.

I have effectively described a relational description of requirements in terms of the SRS.  Section 2 C-Reqs (primarily UCs) are refined into Section 3 D-Reqs (primarily Features).  The Feature reqs are further refined into its Class reqs and/or Class Attribute and Method reqs.  As you probably have notice, I haven't even started discussion on Functional and Non-Functional reqs.

I will break up this discussion into several sub-topics as follows:

1. SRS
----------
The SRS concerns itself with requirements.  EA contains a Requirements Model, but I find that its use lack structure in several ways.  The SRS concerns itself with EVERYTHING that is "Requirements Model" related--the "what, why, when, where (but never how)" of software A&D.

2. SDD
----------
The SDD concerns itself with design.  EA is well developed to handle design with various UML based models.  But "pretty pictures" aside, the SDD concerns itself with EVERYTHING that is "Design Model" related--the "how" of software A&D.

3. Peer Review
----------
I submit a discussion on Peer Review purely as a means to highlight its importance to the process.  In effect, it is another noteworthy concept lacking in the discussion of software development.  Our shop has just recently adopted a peer review process using a commercial package.  In effect, I would like to discuss EA support for the use of these tools where EA can generate a documentation breakout (maybe by a directory structure based on the SRS and SDD sections / subsections with text files for each logical item.  These text files could then easily be added to a review systems as specific pieces as opposed to one large document.  This would help immensely in the debugging of the non-code related A&D documentation (BEFORE implementation) where it is most cost effective.

4. Other
----------
While I don't want to belittle the other documentation standards, I do not want to discuss them in much depth. I think there is enough on this plate to justify limiting the discussion to the SRS and SDD.

I follow this post with SRS and SDD related topics.
Title: The SRS
Post by: HydraKeven on November 15, 2007, 02:18:28 pm
The SRS concerns itself with requirements.  EA contains a Requirements Model, but I find that its use lack structure in several ways.  The SRS concerns itself with EVERYTHING that is "Requirements Model" related--the "what, why, when, where (but never how)" of software A&D.

Our SRS is modeled somewhat thusly:

1. Introduction
1.1. Purpose
1.2. Document Conventions
1.2.1. Requirement Identification
1.2.2. Terms
1.3. Intended Audience and Reading Suggestions
1.4. Project Scope
1.5. References

2. Product Description
2.1. Product Perspective
2.1.1. Operations Concepts
2.1.2. User Interface Concepts
2.1.2.1. “Sample 1” User Interface Concepts
2.1.2.2. “Sample 2” User Interface Concepts (and so on)
2.1.3. Hardware Interfaces
2.1.4. Software Interfaces
2.1.5. Communications Interfaces
2.1.6. Memory Constraints
2.1.7. Operations
2.1.8. Site Adaptation Requirements
2.2. Actors and Characteristics
2.3. Product Features
2.3.1. Use Cases
2.3.1.1. Use Cases for <Some New Subsystem>
2.3.1.1.1. "UC-<Name>” Use Case
2.3.1.1.2. "UC-<Name>” Use Case (and so on)
2.3.1.2. Use Cases for <Some New Subsystem 2> (and so on)
2.4. Operating Environment Constraints
2.5. Design and Implementation Constraints
2.6. User Documentation
2.7. Assumptions and Dependencies
2.8. Apportioning of Requirements
2.8.1. Priorities

3. Specific Requirements
3.1. External Interface Requirements
3.1.1. User Interfaces
3.1.2. Hardware Interfaces
3.1.3. Software Interfaces
3.1.4. Communications Interfaces (Protocols)
3.2.System Requirements: Functional
3.2.1.Requirements of <Some Subsystem>
3.2.1.1.Features of <Some Subsystem>
3.2.1.1.1.System Feature 1
3.2.1.1.1.1. Sequence Diagram
3.2.1.1.1.2. Functional Requirements
3.2.1.1.1.2.1. REQ-1: Some Requirement (and so on)
3.2.1.1.2.System Feature 2 (and so on)
3.2.1.2.Classes of <Some Subsystem>
3.2.1.2.1.Class 1
3.2.1.2.1.1. Attributes of Class 1
3.2.1.2.1.1.1. Attribute 1
3.2.1.2.1.1.2. Attribute 2 (and so on)
3.2.1.2.1.2. Instances of Class 1
3.2.1.2.1.2.1. Instance 1
3.2.1.2.1.2.2. Instance 2 (and so on)
3.2.1.2.1.3. Methods of Class 1
3.2.1.2.1.3.1. Method 1
3.2.1.2.1.3.2. Method 2 (and so on)
3.2.1.2.1.4. Events for Class 1
3.2.1.2.1.4.1. Event 1
3.2.1.2.1.4.2. Event 2 (and so on)
3.2.1.2.2. Class 2 (and so on)
3.3. System Requirements: Nonfunctional
3.3.1. Performance Requirements
3.3.2. Design Constraints
3.3.3. Software Quality Attributes
3.3.3.1. Reliability
3.3.3.2. Availability
3.3.3.3. Security
3.3.3.4. Safety
3.3.3.5.Maintainability
3.4. Other Requirements

Appendices
Appendix A: Glossary (SRS)
Appendix B: Analysis Models (SRS)
Appendix C: Issues List (SRS)

Each Use Cases (2.3.1.1.X.) is modeled as follows:

Use Case ID: UC-<Name>
Use Case Desc:
Created By:               Date Created:
Updated By:               Date Updated:
Actors:
Description:
Scope:
Trigger:
Preconditions:
 1. <Some precondition>
Postconditions:
 1. <Some postcondition>
Normal Flow:
 UC-<Name>.0
   1. <Step 1>
   2. <Step 2> (and so on)
Alternate Flows:
 UC-<Name>.1
   X. <Step X, where X picks up at some step in the normal flow>.
    . <X can be described as substeps if needed, i.e., 5a., 5b.,
    .  etc., to maintain the normal flow steps>.
   [Optional Directive to resume at another (Norm/Alt) step or end]
 UC-<Name>.2 (and so on)
Exception Flows:
 UC-<Name>.X.E.1 (where X is the exception to Flow X)
   Y. <Step Y, where Y picks up at some step in flow X>.
    . <Y can be described as substeps if needed, i.e., 5a., 5b.,
    .  etc., to maintain the referenced flow steps>.
   [Optional Directive to resume at another (Norm/Alt/Exc) step or end]
 UC-<Name>.X'.E.2 (and so on)
Includes:
Priority:
Freq of Use:
Business Rules:
Special Reqs:
Assumptions:
Notes / Issues:

where:
Normal Flow is generally the base or "most used" flow.
Alternate Flows are other acceptably "non-error" flows.
Exception Flows are all the "error handling" exception to the other flows.

The definition between "alternate" and "exception" are understandably weak.
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: Paolo F Cantoni on November 15, 2007, 02:36:13 pm
Hi Keven?,

This is an excellent idea.  I propose we use EA as a worked example - lets start developing the SRS for EA  8) 8)

We could set up stuff on the EA Wiki (see links elsewhere).

Somewhat, but not wholly, tongue in cheek!
Paolo
Title: The SDD
Post by: HydraKeven on November 15, 2007, 03:49:52 pm
The SDD concerns itself with design.  EA is well developed to handle design with various UML based models.  But "pretty pictures" aside, the SDD concerns itself with EVERYTHING that is "Design Model" related--the "how" of software A&D.

Here is an example SDD:

1. Introduction
1.1. Purpose
1.2.  Scope
1.3.Intended Audience and Reading Suggestions
1.4. Document Conventions
1.4.1. Design Identification
1.4.2. Terms
1.5. Requirements Traceability Matrix
1.6. References

2. Architectural Design Considerations
2.1. Design Rationale and Constraints
2.1.1. Assumptions and Dependencies
2.1.1.1. Related Software
2.1.1.2. Related Hardware
2.1.1.3. Operating Systems
2.1.1.4. End-User Characteristicsa
2.1.1.5. Functionality
2.1.2. General Constraints
2.1.2.1. Hardware Environment
2.1.2.2. Software Environment
2.1.2.3. End-User Environment
2.1.2.4. Availability / Volatility of Resources
2.1.2.5. Standards Compliance
2.1.2.6. Interoperability Requirements
2.1.2.7. Interface / Protocol Requirements
2.1.2.8. Data Repository and Distribution Requirements
2.1.2.9. Security Requirements
2.1.2.10. Memory / Capacity Limitations
2.1.2.11. Performance Requirements
2.1.2.12. Network Communications
2.1.2.13. Verification and Validation Requirements
2.1.2.14. Quality Goals
2.1.2.15. Other Requirements
2.1.3. Goals and Guidelines
2.1.4. Development Methods

3. Architectural Strategies
3.1. Implementation Products
3.2. Software Reuse
3.3. Software Maintenance
3.4. User Interface Concerns
3.5. Hardware Interface Concerns
3.6. Software Interface Concerns
3.7. Fault Tolerance
3.8. Memory Management
3.9. Data Management
3.10. Distributed Computing
3.11. Control Issues
3.12. Concurrency
3.13. Communication
3.14. Other Management Concerns

4. Architectural Design
4.1. System Architecture
4.1.1. Top Level Component 1
4.1.2. Top Level Component 2 (and so on)
4.2. Subsystem Architecture
4.2.1. “Previous Component 1” Decomposition
4.2.1.1. Subcomponent 1
4.2.1.2. Subcomponent 2 (and so on)
4.2.2. “Previous Component 2” Decomposition (and so on)

5. Policies and Tactics
5.1. Implementation Products
5.2. Design Variations
5.3. Software Development Standards
5.4. Protocols
5.5. Algorithms and Design Patterns
5.6. Requirements Traceability
5.7. Quality Assurance
5.8. Maintenance
5.9. Interfaces
5.10. System Repository
5.11. Implementation Deliverables

6. Detailed System Design: Data Storage Components
6.1. “Subcomponent 1” Design
6.1.1. Detailed Design Elements
6.1.1.1. Classification
6.1.1.2. Definition
6.1.1.3. Responsibilities
6.1.1.4. Constraints
6.1.1.5. Composition
6.1.1.6. Uses / Interactions
6.1.1.7. Resources
6.1.1.8. Processing
6.1.1.9. Interface / Exports
6.1.2. Detailed Subsystem Design
6.1.2.1. Database Descriptions
6.1.2.1.1. Schema 1
6.1.2.1.1.1. Tables
6.1.2.1.1.1.1. Table 1
6.1.2.1.1.1.2. Table 2 (and so on)
6.1.2.1.1.2. Stored Procedures
6.1.2.1.1.2.1. Stored Procedure 1
6.1.2.1.1.2.2. Stored Procedure 2 (and so on)
6.1.2.1.2. Schema 2 (and so on)
6.2. “Subcomponent 2” Design (and so on)

7. Detailed System Design: Business Components
7.1. “Subcomponent 1” Design (an OO component)
7.1.1. Detailed Design Elements
7.1.1.1. Classification
7.1.1.2. Definition
7.1.1.3. Responsibilities
7.1.1.4. Constraints
7.1.1.5. Composition
7.1.1.6. Uses / Interaction
7.1.1.7. Resources
7.1.1.8. Processing
7.1.1.9. Interface / Exports
7.1.2. Detailed Subsystem Design
7.1.2.1. Inheritance
7.1.2.2. Attributes
7.1.2.3. Methods
7.1.2.3.1. Method 1()
7.1.2.3.1.1. Preconditions
7.1.2.3.1.2. Postconditions
7.1.2.3.1.3. Invariants
7.1.2.3.1.4. Returns
7.1.2.3.1.5. Process
7.1.2.3.1. Method 2() (and so on)
7.2. “Subcomponent 2” Design (an non-OO component: file format, function, etc.)
7.2.1. Detailed Design Elements
7.2.1.1. Classification
7.2.1.2. Definition
7.2.1.3. Responsibilities
7.2.1.4. Constraints
7.2.1.5. Composition
7.2.1.6. Uses / Interactions
7.2.1.7. Resources
7.2.1.8. Processing
7.2.1.9. Interface / Exports
7.2.2. Detailed Subsystem Design

8.User Interface Design
8.1.User Interface 1
8.1.1.Screen Images
8.1.1.1.Screen Image 1
8.1.1.2.Screen Image 2 (and so on)
8.1.2.Objects and Actions
8.1.2.1.Screen Image 1 Objects
8.1.2.1.1.Object 1
8.1.2.1.2.Object 2 (and so on)
8.1.2.2.Screen Image 2 (and so on)
8.1.2.2.1.Object 1
8.1.2.2.2.Object 2 (and so on)
8.1.3.Reports
8.1.3.1.Report 1
8.1.3.2.Report 2

9.Additional Material
9.1.Resource Estimates

Appendices
Appendix A: Glossary (SDD)
Appendix B: Design Models (SDD)
Appendix C: Issues List (SDD)


I've included a Section 6 separate from Section 7 to make a strong distinction between our Database needs and Class Implementation needs.  Section 6 is intentionally before Section 7 as 7 generally back-references 6.  This can be ignored as needed.

Section 4 is design in such a way as to allow Systems, Subsystems, Modules, Packages, etc. to be decomposed down to detailed design objects (Classes...wink, wink, nod, nod) where the actual detailed definitions are reserved for Section 6 and 7.  Detailed design objects in 6 and 7 back-reference Section 4.

Section 8 objects generally back-references Section 7 objects that they use unless these UI elements totally consist of Section 7 objects.  Then, Section 8 summarizes the Section 7 objects that form its UI element.  Yeah, it's a toss up.
Title: Re: The SRS
Post by: HydraKeven on November 15, 2007, 04:56:51 pm
In effect, to simplify, I see the requirements process composed like so:

Requirements:

1. C-Requirements: Requirements the customer can understand
1.1 UI Concepts: Drawings and other related UI info
(subsection as needed)
1.2 Use Cases: High-level "User" to "System" requirements
1.2.2 Use Cases (including a High Level Use Case Diagram as a consequence of the following)
1.2.2.1 Use Cases for a System (including a Use Case Diagram as a consequence the following)
1.2.2.1.1 Use Case 1
1.2.2.1.2 Use Case 2
(repeat Use Case X as needed)
(repeat Use Case for a System as needed)

2. D-Requirements: Requirements the developer can understand
2.1 External Interface needs (new things, more detail for UI)
(Subsection as needed)
2.2 Systems: Functional Requirements
2.2.1 A System
2.2.1.1 Features of a System
2.2.1.1.1 Feature 1
2.2.1.1.1.1 Sequence Diagram
2.2.1.1.1.2 Functional Requirements
(repeat Feature X as needed)
2.2.1.2 Class Requirements of a System (a consequence of a Feature; a Class diagram could be useful driven by the Sequence Diagram)
2.2.1.2.1 Class 1
2.2.1.2.1.1 Attributes
2.2.1.2.1.2 Methods
2.2.1.2.1.1 Instances
(repeat Class X as needed)
(repeat A System as needed)
2.3 Systems: Non-Functional Requirements
(Subsection as needed)

I am divided on the issue of providing Non-Functional Reqs with the Functional Reqs in each System, Feature, and Class when they are specific to that area.  Separating them into a completely separate subsection seems to marginalize them.
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: thomaskilian on November 16, 2007, 10:23:42 am
Thanks for that info :)

I think it would be nice to have a template EAP with that structure. I currently have a structure that fits my needs most times (based on CIM/PIM/PSM). However, sometimes I'd need something looking more like one of the structures you posted.
Title: Re: The SRS
Post by: Paolo F Cantoni on November 16, 2007, 03:19:41 pm
Quote
I am divided on the issue of providing Non-Functional Reqs with the Functional Reqs in each System, Feature, and Class when they are specific to that area.  Separating them into a completely separate subsection seems to marginalize them.
Keven,

You could view the non-functional requirements as "Aspects" (see Aspect Oriented System Development - AOSD) that need to be "woven" into/between the functional requirements.

My AU$0.05
Paolo
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: HydraKeven on November 16, 2007, 04:44:54 pm
In the Requirements Management white paper, pg 13, I take exception to the following statement concerning relationships:
Quote
Realization
Requirements are implemented by model elements, such as use cases, classes, interfaces, components, etc. You may specify this relationship in EA using the realization link. A model element is marked as 'realizing' a requirement. Once this link exists, EA will display the requirement in the element responsibilities tab, in the requirement hierarchy view, and in the dependency and implementation reports, as well as the standard RTF output (See Requirements Documentation (Reports) below for more information on reports).

My argument is based on the IEEE SRS as it provides a well defined, yet flexible, engineering practice.  In it, as well as within other EA documentation, the Use Case definition is that they ARE requirement specifications.  Use Cases are a composite requirement refinement of a base requirement.  Follow this conversation with a customer:

"I want an application that..."
"It needs a screen that..."
"If I do <this>, the system should do <that>."

The application description provides my base requirement.  I can divide this into an aggregation of other requirements based on the customer discussions and further definition.  Now we get to the "screen" requirements.  These are effectively UI Concepts and they most certainly decompose into Use Cases, which are simply a description of a call and response between user and system.  In doing so, it defines requirements for how a system will interact with the user.  These, in turn, are refined into requirements for functions, classes and their attributes, methods, events, and instances.

My point is that all of these decompositions are aggregations of requirements and/or requirement objects, NOT realizations.  Use Cases are simply a mechanism to refine requirements.  They should be decomposed into Features, which are again a refinement of the Use Cases.

The SRS concerns itself solely with REQUIREMENTS and how they decompose along system/subsystem lines.  It drives the design.  The implementation objects, i.e. design objects, are a REALIZATION of these requirements and are in the domain of the SDD.  The SDD only references Use Cases to help a developer understand the purpose of the design elements.  Almost everything we do in Analysis is related to defining or refining requirements.  When done in a well defined manner, the design can be lifted directly from those requirements.  Therefore, the concept of "Requirement Driven Design".

As such, Use Cases DO NOT fall into the same category as Classes, Interfaces, Components, etc.  Maybe this is nitpicking, but as all us computer scientist know: syntax and semantics are important (even in the UML).

So lets get our terminology straight (w.r.t. well documented practices):
----------
Responsibility for a requirement is a "satifying" condition for the requirement.
Use Cases are responsible for nothing.
Use Cases are requirement definitions and help to refine requirements via their related Features.
Sequence Diagrams help to define the Features of a Use Case.
Functions and Classes, their Attributes, Methods, and Instances, "satisfy" or are "responsible for meeting the conditions of" requirements.
----------

Maybe others don't agree with this well defined concept of Requirements and its relationship to Analysis and Design.  However, as EA is a tool for these processes, it should support the development of templates that conform to these well defined practices.
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: HydraKeven on November 16, 2007, 04:58:11 pm
Hey Paolo,

Quote
You could view the non-functional requirements as "Aspects" (see Aspect Oriented System Development - AOSD) that need to be "woven" into/between the functional requirements.


As it is, I do both.  I have a functional and non-functional requirements subsection listed under each Feature and element as needed.  I also have a general non-functional requirements area outside the features as well.  However, each non-func req is also categorical (reliability, availability, security, safety, maintainability, etc.) and this is generally difficult to manage as I get documentation bloat for every atomic element.  They are in effect aspects of the element, but are admittedly second class citizens in the traditional OO development process.
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: Trick on November 19, 2007, 05:20:01 am
Hello,

Very interesting topic!
For I have been looking for a standard document to use with my diagrams.

I would like to add an information about SRS and SDD.
They're apparently also part of a US military standard called MIL-STD-498.
Along with SRS and SDD there are also other requirements documents like the SSS (System/Subsystem Specification).
The SSS is more general and is maybe better for C-Req.
I found those documents there :
http://www.pogner.demon.co.uk/mil_498/
The chapters are described, which make a little easier to understand what's behind the title...

Anyway, a SRS and SDD template would be most excellent!
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: HydraKeven on November 19, 2007, 11:48:39 am
Trick brings up some an interesting point for those of you not completely aware of Software Engineering practices.  In fact there are a whole gamut of SE documents that help control the entire process.  In this discussion, I am focusing on the SRS and SDD, since the SRS as it focuses directly on requirements (which EA seems to want to support properly) and the SDD as it focuses on design.

These two documents, as well as the other, can be developed by an organization to provide a useful, orderly process to developing complex systems.  Here is an outline of the core documents:

Vision and Scope - Software Vision and Scope
SCMP - Software Configuration Management Plan
SPMP - Software Project Management Plan
SQAP - Software Quality Assurance Plan
SVVP - Software Verification and Validation Plan
SRS - Software Requirements Specification
SDD - Software Design Description
STD - Software Test Documentation

Other include the User's Manual and Maintenance Plan in this list.  Variations and other documents also exist.

All of these can be applied to the hardware side, or systems, as well.  Substitute "System" for "Software" if you like.

The "Vision and Scope" document is basically a project kickoff document.

The first 4 documents are project managements documents:
----------
The SCMP documents the management of all configuration items in the project, i.e., everything: personnel organization and responsibilities, policies and procedures, tracking project artifacts (tools, documents, code, etc.), schedules, resources, and maintenance.

The SPMP documents the management of the project's processes, such as an overview, deliverables, reference material, project organization (model, structure, boundaries, responsibilities, management process, technical process, and work packages (their content, dependencies, scheduling, resource requirements, and budget).

The SQAP documents the quality assurance objectives for the project.  It covers quality assurance management, tasks, responsibilities, documentation (referencing all the documents), standards, practices, conventions, metrics, reviews and audits (peer review process, reviewing other documents and processes), testing process, handling problems, securing tools, code, media, and suppliers, recording process, training, and risk management.

The SVVP document documents the verification and validation process.  It covers the V&V team, its members, their responsibilities, and process.
----------

The next 3 documents are the project development documents:
----------
The SRS covers all thing related to the projects requirements such as overview, C-requirements (project description, UI concepts, system interfaces, use cases, assumptions, constraints, dependencies, priorities), D-Requirements (a detailing of the C-reqs: detailed interface requirements, functional requirements as features including a sequence diagram, its specification of feature process requirements, and, if an OO process, detailing the specified class requirements (their attributes, methods, instances, and related events), non-functinal requirements including performance, design constraints, and quality attributes, and any other support materials.

The SDD covers all things related to the projects design.  It is driven directly from the SDD and includes an overview of the project, its architectural considerations(with reviewed alternatives), strategies, and design as a high-level design of the architecture dividing the project into its related systems, modules, packages, etc., and detailing their relationships, any policies and tactics for the design, a detailed design specifying all the processes, functions, files, formats, etc. at the lowest granular level (for an OO process, the classes with their attributes and methods including documentation and pseudo-code to direct the implementation process), and the UI detailed design.  Any additional supporting materials are also included.

The STD covers all thing related to the testing of the design and is driven by the SQAP, SRS, and SDD.  It includes documentation of the testing policy and procedures, test cases for the project including validation and verification of all project requirements present within the implementation, and design flaw documentation and remediation.
----------

The following standards can serve as a reference for most of the documentation presented in this discussion:

IEEE Std. 829-1998 IEEE Standard for Software Test Documentation

IEEE Std. 830-1998 IEEE Recommended Practice for Software Requirements Specifications

IEEE Std. 1008-1997 IEEE Standard for Software Unit Testing

IEEE Std. 1012-1998 IEEE Standard for Software Verification and Validation

IEEE Std. 1016-1998 IEEE Recommended Practice for Software Design Descriptions

IEEE Std 1058-1998 IEEE Standard for Software Project Management Plans

IEEE Std 1540-2001 IEEE Standard for Software Life Cycle Processes – Risk Management

IEEE 12207.2-1997 Industry Implementation of International Standard ISO/IEC 12207: 1995 (ISO/IEC 12207) Standard for Information Technology - Software Life Cycle Processes - Implementation Considerations

MIL-STD-498 Military Standard, Software Development and Documentation, US Department of Defense, 5 December, 1994

The Process Impact site is a good resource: http://www.processimpact.com/

Also, the book "Writing Effective Use Cases" is suggested.
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: KP on November 19, 2007, 09:15:18 pm
Hi Keven,

Too many words! Can you precis please: What exactly are you suggesting or requesting?

My impression after speed-reading your posts is that you are requesting that your models be structured to a very specific format and ditto your output. Both of these things are under your control. You can incorporate Model Templates into MDG Technology files (here's the help page (http://www.sparxsystems.com.au/EAUserGuide/model_templates2.htm)) and this allows you to distribute a standard model structure. Also RTF and HTML style templates can be distributed as reference data, allowing you to define a standard document format for your organization.

I hope this helps,

Neil
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: «Midnight» on November 20, 2007, 04:41:44 am
Neil,

There are a couple of things that Kevin (or anyone) would need done to EA before this kind of thing would be truly possible. As an example, some kind of ability to filter items that are included in reports, based on properties beyond those allowed at present - along the lines of constraints filtered by pre, post, or invariant. I chose this example because it has been requested often, and for quite some time. It might be worth opening a dialog between Sparx and anyone about to take on such a project, so that these roadblocks can be resolved before too much work is invested.

The above said...

I think you're pretty close to the "how to" on this issue. While it would be nice to have this kind of standard setup in EA, it would also be nice to have a dozen or two other standards. But...

IMHO [read that again: IMHO] given the amount of effort involved, this kind of thing is best left to individual customers, or perhaps innovative add-on makers (i.e. let the market decide the value). If Sparx has this level of resources available for development, it would be far better to standardize and extend the core EA product.

David
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: HydraKeven on November 20, 2007, 05:10:09 pm
Neil,

Like the projects we do, this is not a simple topic.  The issues David is pointing out are valid.  The amount of text I use reflects the issues surrounding the problem.  As it is, an accurate SRS document cannot be modeled using the current system.

The main idea is that someone there needs to do some research on formal documentation methods so that EA can meet the greater needs of Software Engineering practices.  Just saying that EA can do this or that is not enough.

It seems like the documentation process has not been thought through and matched up well with well founded industry standards.  The filtering needs would go a long way to resolve this.

Also the way in which EA insists on connecting Requirements object with Use Case object as well as others seems problematic.  IMO, just about everything in the SRS is a "requirement specification".  This means Use Cases should be viewed as requirement specifications and connect to other requirements using aggregation connections within the requirements model.  Use Cases are an aggregation of Features.  Features specify Sequence Diagrams and are an aggregation of Functional and Non-Functional Requirements.  The Sequence Diagrams specify Class/Object/Method/Data Requirements.  Functional Requirements also specify Class Requirements.  Class Requirements are an aggregation of Attribute, Method, Event, and Instance Requirements.  However, EA insists that requirements connect to other model objects as realizations, which tends to break the aggregation (dependency) tree and confuse the idea of requirements specification with design implementation.

To implement this in EA, I need to create a Requirements aggregation (dependency) tree and link the "other" model elements using <<realizes>> connections in a one-to-one manner.  This seems completely redundant, unnecessary, and obtuse.  On this point, EA forces me to confuse the idea of requirements specification with design implementation.

If EA were able to capture the requirements within modeling objects and use a Requirements diagram to model the Requirements Aggregation tree through these element, we could simplify its representation, traceability, and documentation model.

I'm also lost on the whole idea of using "external" and "internal" requirements within model elements.  To me, "internal" requirements are next to useless as they can't be linked in the Requirements tree or referenced in any meaningful way.  It seems to serve as a temporary repository for a requirement until its proper location within a package/diagram is found (to become an external requirement anyway).

See and read "in depth" my other posts on this.  If you think I'm wrong on any of this, show me a detailed HowTo, tutorial, or other help documentation that will clarify these issues.
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: thomaskilian on November 21, 2007, 02:45:31 am
You're speaking "out of my heart" like we say in Germany. I fully agree with what you say and would like that Sparx could rework that requirements stuff accordingly. However, I fear that there's not much hope. We had been discussing that years ago but there was no real change up to now. Somehow I got used to EA's way and adopted it accordingly. The whole thing about capturing and modeling requirements is (my point of view) too complex to be handled with EA alone. During the capturing phase you would need different techniques (like Mind-Mapping) you would do in non-EA tools. Then you need something to really Manage your requirements (what happens if... what impact does it have... etc.) which you can't really do with EA. I'd like to see that EA could cover all aspects but I know that will never be the case. So I know what EA can do and I'm happy that it cover such a bandwith.

However, any improvement is very welcome.
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: HydraKeven on November 21, 2007, 04:31:37 pm
KP reports on another post:

UML
Re: Requirement->Use Case->Activity Diagram

Quote
The connectors offered by the quicklinker are not the only ones you can use, just a list of commonly used ones. If you want to create an aggregation between a requirement and a use case, you may: the aggregation connector is in the "Custom Relationships" toolbox which is opened automatically on opening a Requirements diagram.


This makes many of the the requirements arguments I've been making obsolete.  However, packages refuse to have aggregate connections attached to (from) other elements.  Something about "breaking" the UML.

The only remaining part is aggregating classes.  I found out that I can add odd elements to other elements (ctrl-m) even though the "add..." feature only lists diagrams and links for a Class element.  I was able to add Components to a Class element.  These Components are (artificially) Attributes, Methods, Instances, and Events, each of which contains generic Object elements I can call (artificially) those types and aggregate in the Requirements Model diagram.

This would complete an effective SRS as I can place requirements in each element and hopefully structure the SRS report properly.  But, it is admittedly a hack and a half.
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: Paolo F Cantoni on November 21, 2007, 08:58:34 pm
Quote
However, packages refuse to have aggregate connections attached to (from) other elements.  Something about "breaking" the UML.
Just switch off UML compliance (even temporarily).  See Options menu.

But for curiosity, why are you trying to create aggregations from Packages - which are containers anyway - to other elements?  Aggregation is about meronymy - which I wouldn't have thought applies here.

HTH,
Paolo


Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: HydraKeven on November 26, 2007, 10:11:27 am
I'll answer this and the wide question that it implies as well as provide a suggested enhancement.  I'm sooo verbose! :)

The aggregation is context sensitive.  In this respect, I'm concerned about requirements.  This is a parent-child relationship detailing the refinement of requirements.  You could use "generalize" or "nesting", but EA had already defaulted to "aggregation" for requirements.

While packages themselves can be viewed as an "aggregation" of elements for design, they are not necessarily immune from being a requirements specification as well.  "Package" in this sense means the requirements specification of an actual implementation package (like a Java package which hold class elements), as opposed to an EA project convenience package (like the requirements model package or the class model package which hold the model diagrams).  Therefore, the requirements aggregation tree should shown the refinement of requirements to/from these packages (when they apply). The links points to/from them to indicate the parent-child refinement of the requirements--not the design elements they contain--in a requirements model diagram.

The "Project Browser" shows the meronymy of elements for your project, but those whole-part relationships do not necessarily follow the requirement relationships.  IMO, the project structure should follow some model structure, but as the requirements and design models usually differ, this may not be possible or is exclusive to one of the models.

Another way to show the "package" would be to place all the requirements of the package in the model and use a boundary element to contain them as the package requirements.  The boundary would have the package name anyway.  A third way is to use a requirement diagram element (like a functional requirements diagram) that holds the child requirements.  This becomes a matter of style and how my resulting SRS sections will be generated for the report.

The requirements model diagram should then have an accurate depiction of the requirements for a requirements document--as an aggregation tree.  This model can be extended to include the "realization" links to the design elements for an SDD.  For the package case, this would be a self-edge or a link between the boundary or diagram and the package.  Of course, aggregation exists for design elements as well, but the context is different and its resulting tree may vary greatly from the requirements tree.

The point is to represent a logical parent-child relationship for the requirements while reducing the redundancy.  I shouldn't need to create a requirement element for each Use Case and Feature as they are requirement specifications.  I shouldn't need to create a separate requirement element for each package, class, etc., when I can consider them requirements specifications themselves when specified via a Sequence Diagram for a Feature.   In context, the future "design" element may serve to represent its "present" requirement specification.  An (single) "internal" requirement for the element then begins to make sense.  Other not-so-obvious functional and non-functional requirements that are needed are specifically detailed as requirement elements in the traditional EA-way-things-should-be-done.

NOTE: When I mention tree, this may not be a true tree, as child requirements may have more than one parent.  While this may be view as bad form, consider one or more Use Cases that specifies several Features, each of which may specify the use of a common class.  The SRS document simply needs to  reference its first use and extend it with any additional requirement specifications (other techniques may apply).

My suggested EA enhancement: allow any element to be considered a requirement element, particularly if the element contains an internal requirement (a single internal requirement could be marked as its self specifications), especially when it is used in a requirements diagram.  Then, all the child links could be viewed and set as external requirement links within each element (properties->require).  By specifying the external requirements within each element, a requirements diagram and matrix could be automagically generated.
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: Paolo F Cantoni on November 26, 2007, 11:31:29 am
Hi Keven,

There are a number of issues with your post above, which I won't directly quote (due to its length ;)  - although you'll note if you check most of my posts, I'm not averse to trying to make things clear by not skimping on words! :))

So far, you haven't said if you are new to UML or not.  However, you have been "sucked in" by its use of common terms in "English" and other natural languages and most technical languages and their use within UML.

Please don't take offence (as others have previously done) in mistaking my commentary as a personal slight.

The first problem is the use of the terms parent-child(1).  In UML that term is used exclusively for the Generalization relationship.  Realization is not parent-child (I think it's specification-instance - but I'm not certain) and Aggregation is whole-part (meronymy).

Secondly, although UML uses the term package, it doesn't use it in the same way as we would normally accept.  Thus a Java package isn't a UML package.  This is unfortunate as UML "steals" all these common terms and gives them its own twist.

If you haven't yet read the [size=13]UML 2.1.1 Superstructure (formal)[/size] (http://www.omg.org/cgi-bin/doc?formal/07-02-03) Specification.  Now may be a good time to do so... (A riveting read at over 700 dense pages).

You may care to chase up some previous posts of mine on the subjects above.  They may help sort out some of the language.

HTH,
Paolo

(1) I once attended a talk at the Sydney (Australia) Patterns Group where the speaker was using the term "sibling" relationship for what was clearly a "parent-child" relationship.  When I queried him on the definition of sibling, both he and fully 1/3 of his audience had an incorrect definition!  No wonder we can't build systems together...  J.R. Abrial was right!


Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: Paolo F Cantoni on November 26, 2007, 11:43:57 am
Quote
NOTE: When I mention tree, this may not be a true tree, as child requirements may have more than one parent.  While this may be view as bad form, consider one or more Use Cases that specifies several Features, each of which may specify the use of a common class.  The SRS document simply needs to  reference its first use and extend it with any additional requirement specifications (other techniques may apply).
As a further example, but one more easily rectified!  

Consider the term tree for those hierarchies that have exactly one superior and lattice for those that may have more than one.  Hierarchy can be used as a generic term where the exact nature is NOT known.

In many places hierarchy and tree are used to denote the same thing - but this is (in my - and most dictionaries' - view) incorrect!  Consistently using hierarchy, lattice and tree in this way will solve a lot of problems.

HTH,
Paolo

(Note: if you intend to aggregate requirements, you needed to say: since each requirement may be part of more than one aggregate)
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: Paolo F Cantoni on November 26, 2007, 11:51:17 am
Quote
My suggested EA enhancement: allow any element to be considered a requirement element, particularly if the element contains an internal requirement (a single internal requirement could be marked as its self specifications), especially when it is used in a requirements diagram.  Then, all the child links could be viewed and set as external requirement links within each element (properties->require).  By specifying the external requirements within each element, a requirements diagram and matrix could be automagically generated.
Keven,

This one is a bit more serious.  If item contains 'X' then it is not an 'X".  Thus an element that contains a requirement is NOT a Requirements Element.

I suggested to you offline (and to other posters online)  that an EA "internal" requirement is best conceptualized as an an element's responsibility.  I adopted that view the second week I started using EA and have never regretted it. Nor have I found a situation where that did not work correctly.  EA has done us all a great disservice in making its user interface so self inconsistent - notwithstanding its claim to an intuitive interface.

HTH,
Paolo
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: HydraKeven on November 26, 2007, 04:00:33 pm
No offense taken.  It is the purpose of the discussion to clarify.  As such, I never claimed this discussion was based on or was restricted to UML definitions or terminology.

By the way, I am a visual computing / graph grammar specialist.  There have been several attempts to model the UML as a visual language.  Every parsing process I know about for the UML is sketchy at best.  If the UML was a true, well defined language, we could dispense with "code generation" and execute UML models directly.  Work continues in this direction.

No, I am not new to the UML--I just happen to disagree that the UML is "correct".  It applies rigidity in its definition while rejecting rigidity in its use at the same time.  It supplies a definition, but allow the user the flexibility to interpret that definition for their own use.  As such, the UML does not define how a user should specify, construct, or define design.  It simple provides some basic tools to model them.  It is based on graph theory, but then bastardizes its terms to define itself.  It is fairly well defined in this respect.

As you say,
Quote
This is unfortunate as UML "steals" all these common terms and gives them its own twist.

As far as terminology and definitions I use are concerned, I make the following disclaimers for your benefit:
----------
1. For any graph you care to consider, whether called a hierarchy, lattice, tree, etc., when a single node is selected as a root node, any sufficiently satisfying spanning tree defines a parent-child relationship from root to leaves.  Therefore, I use the commonly accepted definition for parent-child, not the UMLs.

2. All edges in the UML are simply labeled edges that specify context.  I implied that "aggregations", "generalizations", and "nestings" are parent-child.  I should also state they are directed edges which limits and defines the parent-child relationships within a satisfying spanning tree.

3. You said
Quote
although UML uses the term Package, it doesn't use it in the same way as we would normally accept

I counter that UML uses the term "Package" precisely as user intends it to be used.  It is a generic container tool.  It is the user's responsibility to define its use within a project and is used pervasively by various UML tools in the code generation process for languages, such as Java, for specifying package constructs.

4. It is commonly accepted that, w.r.t parent-child relationships, a child may have one or more parents.  The selection of the parent-child edge within the spanning tree is arbitrary as long as it satisfies.  Therefore, at will, we may selected the satisfying edge for the tree.

5. For any "hierarchy", a comprehensive spanning tree can be constructed by arbitrarily adding a single root/parent node that connects all "superior" nodes as children.  This process applies to any graph.  I apply this to requirements modeling by declaring a "single root project / application / system" requirement node to which all other requirements aggregate.
----------

To address your issue on "Requirements Element", this issue is no more serious than the way in which a user defines the use of the tool.  When I say "contains", I am stating in the request, a desire for a single internal requirement to define the element w.r.t. requirements as a requirement element.  Categorically, I desire elements to be "requirement" only, "design" only, or both (in general, both).  A simple way to do that is to declare the generic element with a requirements definition (a requirements element "contains" a requirements definition, its properties, which IS the requirement).  This definition should be within the generic element--as its internal requirement properties.  I do NOT want an external definition as it is redundant (see below) and does not provide the typing mechanism I need to specify the SRS (I need UI Concept, Use Case, System, Feature, Class, Attribute, Method, Instance, Event, etc., types to properly section the document).

You say,
Quote
an EA "internal" requirement is best conceptualized as an an element's responsibility

You may choose to view internal requirements as an objects responsibilities.  I have no use for internal requirements defined in this manner.  If an element it "responsible" for something then it "realizes" one or more "requirements" and each can be defined as external without exception.  This leave the realm of requirements specification and enters design.  I am not concerned with relationships between requirements and design.  This is well established in EA.  I am only concerned with the proper relationships between requirements.

Here is an example problem: EA views Use Cases as "design" elements as, by default, it realizes (external) requirements.  I can manually specify aggregate relationships for UCs in a requirements model, but EA still does not view them as requirements (they do not show up as external requirement "parts" for its "whole", if you wish).  I have never seen anyone "design" a Use Case, so it should not "realize" anything.  I have seen a system "realize" a Use Case and a Use Case used to specify the "requirements" for other requirements that, in turn, specify "design" elements that are "realize" or implemented,  such as classes.  Therefore, strictly speaking, a Use Case element is a "requirements" element.  Systems, subsystems, modules, packages, classes, etc. are generally "design" elements.  They "fulfill", "realize", or "are responsible for fulfilling" a requirement such as is specified in Use Case, Feature, and Class requirements.

However, there is no such thing as a class "requirement" element within EA.  We can arbitrarily declare one, but it is no different than any other requirement.  And, as I need to define a class "design" element for it anyway, there is a one-to-one relationship (I declare its need once in the requirements and its fulfillment once in the design) --therefore, it is completely redundant.  If I could declare the class element as a "requirement" within the context of the requirements model diagram, I could use the same element in a class model diagram, reduce the redundancy, and self-satisfy its "requirement" definition with its "design" definition.

Enough for now.
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: KP on November 26, 2007, 04:47:48 pm
Quote
I have never seen anyone "design" a Use Case, so it should not "realize" anything.

UML 2.1.1 Superstructure says: "A Realization signifies that the client set of elements are an implementation of the supplier set, which serves as the specification. The meaning of ‘implementation’ is not strictly defined, but rather implies a more refined or elaborate form in respect to a certain modeling context."

This suggests it's quite OK for a use case to realize a requirement.
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: HydraKeven on November 26, 2007, 06:46:43 pm
As stated, it also suggests that a "requirement" could realize a "Use Case" as "implementation" is user defined.  All this does is support the idea of "user context" for the model.

But, I'm concerned with more practical matters within the context of standard practices for requirement specification as given by IEEE (the topic title).  So, while its OK for a Use Case to "realize" a requirement in "some" model (and EA support this), it doesn't mean that it should be done or is done in practice.

More importantly, I want to model Use Cases (and other element types) AS requirements (which EA does not support).  The purpose is to support requirement decomposition via some connector type.  Aggregation is the currently supported mean for requirement decomposition within EA (and seems proper for its "whole-part" definition).  Doing so would follow closely the IEEE context for the SRS (requirements specification).

I can make a model show this, but the underlying support is missing.  Within a requirements model diagram, the "part" elements are not truly modeled as external requirements for the "whole" element.
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: Paolo F Cantoni on November 26, 2007, 07:14:33 pm
Hi Keven,
Quote
No offense taken.
Whew!  Sometimes my contributions are mistaken...
Quote
It is the purpose of the discussion to clarify.  As such, I never claimed this discussion was based on or was restricted to UML definitions or terminology.

By the way, I am a visual computing / graph grammar specialist
Does that mean you're into Conceptual Graphs and stuff like that, based on Pierce's work?
Quote
There have been several attempts to model the UML as a visual language.  Every parsing process I know about for the UML is sketchy at best.
Agreed!
Quote
 If the UML was a true, well defined language, we could dispense with "code generation" and execute UML models directly.  Work continues in this direction.

No, I am not new to the UML--I just happen to disagree that the UML is "correct".
Won't get any argument from me on that score... :)  Nevertheless, it is better than the "curate's egg".
Quote
It applies rigidity in its definition while rejecting rigidity in its use at the same time.  It supplies a definition, but allow the user the flexibility to interpret that definition for their own use.  As such, the UML does not define how a user should specify, construct, or define design.  It simple provides some basic tools to model them.  It is based on graph theory, but then bastardizes its terms to define itself.  It is fairly well defined in this respect.
Agreed...

I've tried to come up with a consistent viewpoint of how to use UML (and EA) effectively.  However, every few months, something comes up which causes me to modify my internal metamodel (for the better).  This has happened 4 times in the last year, this is likely to be another - so for that I thank you.
Quote
As you say,
As far as terminology and definitions I use are concerned, I make the following disclaimers for your benefit:
----------
1. For any graph you care to consider, whether called a hierarchy, lattice, tree, etc., when a single node is selected as a root node, any sufficiently satisfying spanning tree defines a parent-child relationship from root to leaves.  Therefore, I use the commonly accepted definition for parent-child, not the UMLs.
Yes, I understand, but isn't it the case (not being a graph theorist of any note)  that the edges themselves normally don't have any (different) semantics?
Quote
2. All edges in the UML are simply labeled edges that specify context.  I implied that "aggregations", "generalizations", and "nestings" are parent-child.  I should also state they are directed edges which limits and defines the parent-child relationships within a satisfying spanning tree.
So, do you always qualify the parent-child by the type?  Not criticizing, just asking... :)
For my own part, I use origin-destination for directed edges.  I'm not convinced that the origin is always the parent nor the destination the child.  I do agree that for the types you cite, since they are necessarily, acyclic one can make that assertion - but only, I hope you'll agree, where the graph is acyclic.  Association graphs, for example, wouldn't allow this parent-child designation.  Have I got that right? Remember I'm learning here...
Quote
3. You said
I counter that UML uses the term "Package" precisely as user intends it to be used.  It is a generic container tool.  It is the user's responsibility to define its use within a project and is used pervasively by various UML tools in the code generation process for languages, such as Java, for specifying package constructs.
Since we use packages almost exclusively for grouping and I'm not a Java expert by any means, I'll defer...
Quote
4. It is commonly accepted that, w.r.t parent-child relationships, a child may have one or more parents.  The selection of the parent-child edge within the spanning tree is arbitrary as long as it satisfies.  Therefore, at will, we may selected the satisfying edge for the tree.
No problem, with parent-child.  I just reserve tree for those children that can have only one parent, and lattice for those that could have multiple.
Quote
5. For any "hierarchy", a comprehensive spanning tree can be constructed by arbitrarily adding a single root/parent node that connects all "superior" nodes as children.  This process applies to any graph.  I apply this to requirements modeling by declaring a "single root project / application / system" requirement node to which all other requirements aggregate.
Agreed.
Quote
----------

To address your issue on "Requirements Element", this issue is no more serious than the way in which a user defines the use of the tool.  When I say "contains", I am stating in the request, a desire for a single internal requirement to define the element w.r.t. requirements as a requirement element.  Categorically, I desire elements to be "requirement" only, "design" only, or both (in general, both).  A simple way to do that is to declare the generic element with a requirements definition (a requirements element "contains" a requirements definition, its properties, which IS the requirement).  This definition should be within the generic element--as its internal requirement properties.  I do NOT want an external definition as it is redundant (see below) and does not provide the typing mechanism I need to specify the SRS (I need UI Concept, Use Case, System, Feature, Class, Attribute, Method, Instance, Event, etc., types to properly section the document).
OK... I think we can agree to disagree on this.  I agree we need better typing of external requirements, but it will be interesting to watch how your vision pans out...
Quote
You say,
You may choose to view internal requirements as an objects responsibilities.  I have no use for internal requirements defined in this manner.  If an element it "responsible" for something then it "realizes" one or more "requirements" and each can be defined as external without exception.  This leave the realm of requirements specification and enters design.  I am not concerned with relationships between requirements and design.  This is well established in EA.  I am only concerned with the proper relationships between requirements.
Just to clarify, Requirements (in my terminology) are what I must do.  Responsibilities are what I can (have authority to) do... While they are intimately related, they aren't the same to me - so maybe we have been talking at cross-purposes.
Quote
Here is an example problem: EA views Use Cases as "design" elements as, by default, it realizes (external) requirements.  I can manually specify aggregate relationships for UCs in a requirements model, but EA still does not view them as requirements (they do not show up as external requirement "parts" for its "whole", if you wish).  I have never seen anyone "design" a Use Case, so it should not "realize" anything.  I have seen a system "realize" a Use Case and a Use Case used to specify the "requirements" for other requirements that, in turn, specify "design" elements that are "realize" or implemented,  such as classes.  Therefore, strictly speaking, a Use Case element is a "requirements" element.  Systems, subsystems, modules, packages, classes, etc. are generally "design" elements.  They "fulfill", "realize", or "are responsible for fulfilling" a requirement such as is specified in Use Case, Feature, and Class requirements.

However, there is no such thing as a class "requirement" element within EA.  We can arbitrarily declare one, but it is no different than any other requirement.  And, as I need to define a class "design" element for it anyway, there is a one-to-one relationship (I declare its need once in the requirements and its fulfillment once in the design) --therefore, it is completely redundant.  If I could declare the class element as a "requirement" within the context of the requirements model diagram, I could use the same element in a class model diagram, reduce the redundancy, and self-satisfy its "requirement" definition with its "design" definition.

Enough for now.
Yes, interesting viewpoint.  I was of the view that a use case specifies HOW an requirement was to be realized.  But I concede that there are aspects of your statement above that are worth exploring.  Perhaps others (bruce - over to you?), may have more to say.  As I said earlier, this is a chance for all of us to explore our understanding and perhaps enrich/change it...

Paolo
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: thomaskilian on November 27, 2007, 09:51:42 am
Re "Use Cases are not designed": I do not concur with that aspect. As a matter of fact a UC specification is written as (first!) part of the system design. Right after the informal requirements are collected from the stakeholders. Writing the UCs correctly is definitely a design process to me. In that respect I think that it actually Realizes the informal requirements.

N.B.: Very, very interesting thread. Unfortunately I'm very, very short of time :(
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: jeshaw2 on November 27, 2007, 11:34:42 am
I agree with Thomas.  I view a Use Case as a protocol specification between actors and the system.  If the protocol does not change from a prior system, what new business benefits do the stakeholders gain?  Yeah, one may argue for cost reduction, but new systems aimed at revenue enhancements or operational improvements yield a bigger payback.
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: HydraKeven on November 27, 2007, 05:03:07 pm
We must keep in mind that I'm presenting the concepts of "requirements specification" and "design" in terms of the IEEE specification for the SRS and SDD.

Writing requirements IS a design process for the analyst.  It presents what a system MUST do.  It give insight in to the systems design.  Designing a proper requirements specification for a system is essential to designing to the system.

Quote
As a matter of fact a UC specification is written as (first!) part of the system design. Right after the informal requirements are collected from the stakeholders. Writing the UCs correctly is definitely a design process to me. In that respect I think that it actually Realizes the informal requirements.


This is exactly were confusion creeps in with regards to the difference between "software requirements specification" and "software design".  Stakeholders can be involved directly in UC specification, so UCs can also be part of the "informal" requirements.  UC are (first!) written to clarify these informal stakeholder requirements in terms of what you envision as the system's interface with the user--they refine them and give you ideas about the design, but they are far from "being" the design.  You can surely claim that they "define" aspects of the grosser informal requirements.  But they are still just requirements.  In the context EA presents, a requirement to requirement link would be an "aggregation"--their choice.

The result is that UCs tell us what, when, where a system should do things, which are requirement specifications.  In general, they leave out how as that is a design specification.  You would say "this" system/subsystem/module/class/whatever fulfills "that" UC specification.  In the context EA presents, that would be a "realization"--their choice.

If you suddenly drop requirements specification at the "informal" requirements, then I would say that you are lacking a complete requirements road map to your design.

Quote
I view a Use Case as a protocol specification between actors and the system.


You can and should.  These "high level" protocol specifications are completely within the realm of requirement specifications.  But, they leave out many, if not all, of the design detail--how you go about implementing the protocol.
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: thomaskilian on November 28, 2007, 12:59:24 am
It's quite a while ago since I finished my Software Engineering studies (21 years to be more exact). And I had ever since the opinion that SE is very much under-estimated. However, the current discussion now tends to lead to a much too abstract/educational level. It seems to depended on the definition of Design. And depending on that Design Definition you attach the constraint of using Aggregation or Realization relationships. Now: what do you think that Design is actually? Where does it start? Right when you collect requirements in a Smart way? I would say so. There is no simple Requirements Collection Phase. This IS design.

Actually the design already starts with the idea of Change. If you do not Design that idea well, it gets lost. If this Design process produces a paper of Goals and Benefits then you have a project. The Design continues with Smart collection of requirements (still Design towards the Final System). Then Use Cases and so on.

Now where do you think, Design starts?
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: sargasso on November 28, 2007, 03:02:00 am
(Since I was asked)

In general, I concur with Keven's viewpoint.


In fact, on reflection, I concur with most of his observations.  I always find, when faced with "issues" of this type, to go back to whatshisnames original definition of use cases.  They "had" a clarity and a defined scope, viz "what" and not "how".

(Aside) As far as "when" is concerned, I presume you mean "on what external stimulus is the use case invoked".

Pundits to the left of me, pundits to the right and here I am, stuck in the middle with UML  (apol)

bw
bruce
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: Paolo F Cantoni on November 28, 2007, 04:37:34 am
Quote
whatshisnames
Ivar Jacobson?

Paolo
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: jeshaw2 on November 28, 2007, 05:20:02 am
A very interesting thread so far, but I would caution against the Systems Approach thinking (aka. the "water Fall" ontology).  If Design has a start, both an end and a sequential ordering of processes could be implied.  

Known generically as the Scientific Methodology (aka. RUP), parallel iterations are today's "Best Practice".  In that ontology, Requirements Gathering, System Design, Software Development, etc. are all timeless, parallel processes.  They began with the Big Bang and will end with the Big Collapse (I think  :-/).  Kinda like my wife's never ending shopping trip. :D Process boundaries are fuzzy, not crisp as in the Water Fall approach.

Project beginings, endings and internal milestones are management artifacts imposed on a system's process for defining points of review and approval. Process boundaries are management vehicles for assigning areas of accountability, and perhaos, modus operandi. For clarity of thinking, I like to keep the Whos and the Whens apart from the Whats, the Whys, and the Hows.

Just my descending $0.02 US

Jim
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: HydraKeven on November 28, 2007, 12:55:26 pm
Thanks for everyones input so far.  The written word in this manner is often interpreted with tones not intended by the authors.  I struggle with myself to read these with only the most soft and gentle of tones.

Wow, this became far longer than I intended.

First, I'll go back and address some of Paolo's questions.

Paolo - you are an incessant name dropper :)
---------------
---Off Topic---
---------------
No, not Peirce's directly--but, yes, as far as grammars as logic constructs.  I assume you are referring to Sowa's work on Conceptual Graph Notation for the existential graphs of Charles Sanders Peirce (as opposed to the other Pierce, Peirce vs Pierce).  My interests lie in grammar notation--specifically inferring grammar from graph data to mine for structure and applying the grammar by parsing graph data for validation or intersection.  Applications relate to the ever elusive semantic web and web page restructure for alternative display devices among others.

Try the more recent works of Bartsch-Spörl; Rekers and Schurr; Zhang, Zhang, and Cao; Kong; Inokuchi, Washio, and Motoda; Kuramochi and Karypis; Yan and Han; Holder and Cook; Joyner

Quote
...edges themselves normally don't have any (different) semantics

Not at all.  It has been traditional to apply semantics only to nodes (or at least ignore the edge semantics).  However, a graph can be transformed in many ways.  As a simple graph, [N1]->[N2], let "->" specify a directed edge.  Then, let [N1]--[From]--[To]--[N2] specify an undirected equivalent (where "->", "From", and "To" all have domain context--some may argue [N1]--[To]--[From]--[N2]is also a proper transformation, depending on your reference).  Then, "->" encapsulates the "[From]--[To]" semantic relation.  Also, "From" and "To" could be set as node ports in extended graph notations.  Therefore, we are free to give "type" to nodes and edges to express semantics.   Try this: N1 + N2 = N3 becomes
 [N1]-+->[N3]
 [N2]-+--^
is also
 [N1]->
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: Paolo F Cantoni on November 28, 2007, 03:21:00 pm
Keven,

from the foregoing, I got to thinking...  (Dangerous, I know!)

If we viewed traditional "Requirements" as declarative requirements and Use Cases as a form of procedural requirements - would that provide a conjunction of view?

Personally, I think I could live with that.  It would also imply that if one wanted to list ALL the requirements in a model, one would get both...

It's like the responsibilities/requirements argument...  I a well formed system "If I can do something, I must be able to do it" - but we don't always have a well formed system (at least not initially)!  The Engineering/Science/Art is about resolving the competing factors.

Anyhow, just a thought for others to ponder and provide feedback on...

Paolo
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: Paolo F Cantoni on November 28, 2007, 03:25:22 pm
Hi again Keven,

What's your view on the role of the "Feature" element in EA in all this?  We have to do EN50128 design reviews and we use the "Feature" element to describe at a high (aggregated) level what the subsystem can do...

I guess sort of like an aggregated set of responsibilities.

TIA,
Paolo
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: sargasso on November 29, 2007, 04:07:09 am
[As a tester]
Well y'all, ya know, its all very good and well to have a reel good set of bloo-prints to build this here chookshed.  But ya know what I reckon? I aint seen one blooprint set yet that matches the construction, 'cept for the set used by the builder himself and covered in pencil, crayon, mud and chickensh*t.
[/As a tester]

Now, therein lies the crutch of the problem.  ;)

Between the dream (SRS) and the reality (the software delivered) lies a devil ... time.  And over time, things change.  Things like priorities, costs, estimates, budgets the weather, the government, decisions on what "I" really meant as "that requirement" and all those things that were "givens" at the start of the project ... like the delivery platform for instance.  (Ed: tautology?)  Maybe even things like "consistency" change, who knows?

[As a test manager]
Dramatis personnae
Pete (an esquire, commanding a view of his quarter acre)
Pam (Pete's significant other)  
Bob (a builder)

Act I, Scene I : Pete's Kitchen, one Saturdee arvo
(FX) Dialtone, digital dialing then ringtone (off)
Pete: Aw, g'day Bob, I wan'cha to build me a chook shed
Bob (O/S): Yeah? No probs, Pete.  How big?
Pete: Ooh, about 16 foot by twelve foot.
Bob: Yeah OK, I'll come round tomorra about lunchtime and give ya a quote.
Pete: OK mate, see ya then.
Bob: OK
FX: (Quick fade)

Act I, Scene II : Pete's backyard, "tomorow".
Bob: So, where do ya want the shed Pete?
Pete: Over here, near the back door.
Bob: Yeah OK. By the way, how many chooks ya got?
Pete: 'bout a dozen, I s'pose.
Bob: Well, I suppose we'll have to get Council permission then.  But that shouldn't be too much of a problem. I mean, there's no construction diffo's.  By the way, what's that  they're building next door?
Pete: Aarr, dunno. I think he's a vet or sumthing.
Bob: Yarr OK, anyway I'll get young Bob to knock up a cupla drawin's to go to tha Council. Should only take 'im a cuppla days or so.  I reckon we can knock this off for, say, eight or nine hundred bucks or so.
Pete: Ar, you beaudy! That's what I reckoned, too.  Let me know when you can start.
FX: Fade out with upbeat theme.


Act II, Scene I (some weeks later) : Pete's kitchen
FX: (O/S theme suggesting distant storm clouds, fade in to ..)
Pam: (Drumming fingernails on formica bench top) You! Just what exactly, are you doing.  What and why the hell are we spending money on Bob the builder!  Our kid's need braces, I'm still driving that bomb, and the neighbours are complaining about Bob's kid continually parking his ute on their lawn, what is he doing here anyway.
Pete: He's just measuring up the block for the chookshed.
Pam: The chookshed, the damn chook shed, all I asked you was to get off your damn arse away from the footy and go to the supermarket and get a dozen eggs for the kid's lunches.  What ever possessed you to decide we needed a chookshed.  Jeesurs can't you just for once understand that we are trying to run a family here!
FX: Phone rings
Pete: Got it, yeah hello.
Bob: (O/S)  G'day Pete. We got a little problem with th' shed.  It looks like we gotta put in extra drainage to satisfy the Council.  And it looks like we oughta move it away from the kitchen an' over in front of the pool.  But I reckon that we should be sweet if we don't strike any other problems.
...
By the way mate, I'm gonna have t' get a bit of a pump from ya on this project, can ya give us a advance of a cuppla grand? There's a lot of people I need to keep onside to get this one through?

Act II, Scene II (in the front yard, outside Pete's house. (In the driveway as a matter of fact))
Pam: C'mon kids get ina car!
FX: Mobile phone ringing, dog barking, 12225db plane landing  overhead
Pete: (into phone) Yeah what?
Bob: G'day mate, listen.
Bob: I reckon we gona have to do something about those foxes.
Pete: What "cloudy" foxes?
Bob: Well, ya know that there's been a ...
FX: 6.23^10db jet engine sound
Bob: ... so I reckon we're going to ha' to reee-assess the basic safety precautions ...
FX: several dozen Challenger launches combined with the dog biting child number three.
Bob: so, you OK with that?
Pete: OK with what? Oh sh*t I forgot to get that "Section 3" you needed, .. never mind, I'll call you tomorrow.  By the way, we're still going with your $800 price aren't we?
FX: Something like Krakatoa exploding, Mercury's orbit intersecting our's or at least a small supernova.
Bob: ... so you OK with that too?
Pete: Listen, I'll have to call you in the morning. Don't do anything until then, OK?
FX: Sound of dead phone connection (???)

Act III, Scene I (many weeks later)
FX: (O/S theme suggesting an evil or at least very bad news, say a courtroom as the judge dons the black kerchief)  

.... some may call me a cynic :-)


Act III, Scene MCLXIII
FX: Fade in to reprise of original kitchen scene with Dialtone, digital dialing then ringtone (off)
Pete: Aw, g'day Bob, I wan'cha to build me a chook shed
Bob (O/S): Yeah? No probs, Pete.  How big?
Pete: Ooh, about 16 foot by twelve foot.
Bob: Yeah, no problems mate. I'll get our young Julia to drop round tomorra about lunchtme and get the paperwork started, I reckon we'll have it done come Michealmas. By the way, 'ow much d'ya reckon ya can pay for this project.

FX: Fade ... to black, ... or white, ... or just another day.

merry Hanukah
bruce

p.s. I may revise this.

Revision the first: Yes I know it's obtuse
Revision the second: Act II Scene II
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: «Midnight» on November 29, 2007, 04:49:33 am
Quote
...
Revision the first: Yes I know it's obtuse

[As a Reader]
I was with you up to this point bruce, but I'm willing to look again

So where's this obtuse bit?
[/As a Reader]
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: sargasso on November 29, 2007, 05:08:39 am
'probly just the cycle bit ?
"like a circle in a circle,
like a spiral in a wheel"

or, like whatever...
;D

bruce
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: HydraKeven on December 03, 2007, 06:03:51 pm
Paolo -

On Reqs In General: Concerning the SRS, the requirements form a basic contract between developer and stakeholders.  The SRS is what the developer says the system will do and the stakeholders agree or disagree, modify, iterate.  It is a forum document in that respect.

On Use Cases: Yes, I would tend to agree.  We could debate over formal names and how we view them forever.  They can be viewed as protocols, for instance.  In any case, I maintain that they describe "reqs" first and foremost--what a system should/must/can do AND are a tool for exposing more detailed requirements.

On Features: I also view these as requirements in the same respect as Use Cases, but at a lower level--the SRS definition of "Use Case" is a more customer centric requirements and a "Feature" is a more developer centric requirement.  They provide the requirement details for a subsystem described in/by a Use Cases.  They include a Seq. Diag. and functional reqs.  Class reqs can be a sub-specification of this or separate.  So you should be able to see a clear path in terms of requirements (and their aggregation?): SomeHighLevelReq -> UI Concepts and UCs(more detail) -> Subsystems(more detail) -> Features(more detail) -> Seq Diags, Functional Reqs, Class[attribute, method, instance, event reqs](most detailed) [your organizational structure may vary].  The non-functional reqs may also be somewhere in there or may be overall system concerns or both.

Bruce -

Your humor, sarcastic or not, is very appreciated!  It highlights the sorry state of affairs for software development.  It also show how we are sometimes in a wacko, surreal, learn-as-we-go industry.  I state with a fair amount of certainty that errors in communication are our number one problem--"blooprints" or not.  You almost make one of my points: having an implementation based on an SRS and SDD--whether it exactly follows them or not--is far better than not having them at all.  They are documents for everyone involved to share points of discussion.  If used properly, they improve the process and the implementation.

That reminds me of the probe that crashed into Mars in 1999.  The documentation was properly written, but not properly used.  Other procedures were also not in place to catch the mistake.  So in the end, the time it would have taken to use the system properly would have cost them far less than the billions that were lost in the instant the probe was destroyed.

I agree that change over time is a major factor.  Using systems and procedure that capture and manage change should be a part of any project.  In fact, they should be the core of a project's risk management strategies (we all know about "risk management", don't we?).

All -

I know it's not a perfect "Walgreen's" world.  I understand that we don't generally start with information that lends itself to develop a well formed system, much less friendly stakeholders that know what they want or all the issues involved.  But, our job is to create a well formed system.  We may not know all the answers either, but we should at lease be asking questions and using good SE techniques to help capture, isolate, and solve the problems we face.  I want to use EA as a tool for those techniques.

And it should be scalable.  If all you need is a "chook shed", any failure might be acceptable and the level of SE needed may be minimal.  But if you need to build a skyscraper...well, we're talking about systems that NEED to be well managed.  Right? (everyone take their Prozac and nod :) )
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: jeshaw2 on December 03, 2007, 07:05:48 pm
Quote
I agree that change over time is a major factor.  Using systems and procedure that capture and manage change should be a part of any project.  In fact, they should be the core of a project's risk management strategies (we all know about "risk management", don't we?).

It is said that when something is measured, it is changed.  As a corollary, when something is analyzed, it is changed.
 
In systems development, we must not only capture and manage change, we must desire and embrace change wherever we can instigate it.  

Life is change; without it, there is no life.  Are we not all change masters?

-Jim
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: thomaskilian on December 04, 2007, 03:25:42 am
To take it one step further: What is the true requirement? The one that I write down after talking to the stakeholder, or the one that he/she was actually thinking of? You all know it. No matter what I have written: in the end we start disputing about the meaning - the real truth. So life is not only change. It is also a permanent compromise.
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: sargasso on December 06, 2007, 06:28:52 am
Mega culpa! OK OK mea culpa.

I was just trying to illustrate the type of problem we see at the "end" of the project [as a tester].  It has been patently  obvious to many that, over the life of a   p r o j e c t  , that "thangs quite oftend and ginrally" (sic) change.  Some of these things are well understood in the SE world, things like budgets and constraints, and frequently even the "P" word, policy.  

I suppose, all I'm trying to say is, for the sake of your own sanity, consider why documentation has failed this craft before.

To me it's not because it was not well structured.  Further, I have read through ALL of the last three pages looking (yet again) for "good ideas". Yet I am still not convinced that the "structured analysis" approach is feasible. Every day that work I see trade offs, concessions, bitter and sometimes "better" arguments about ....

   getting better value to the "user-floor"

Some ten years ago I read "whatisnames" (1) treatise on usecases and the more and more that I get up in the morning and head off once more to do "battle" with the same old lack of communication between the "receivers" and the "providers" of IT systems, the more I believe and see what he was trying to say:

"I just want to make a phone call"  
"What's a phone call"
"I just want to talk to Grandma"
"So, you want us to build a device, that will, given the incumbent Government develops the necessary infrastructure, legislates and empowers the defined demographic to intitiate and maintain (until such times as the medium is disconnected by either party, such parties including the initiator, the recipient and the infrastructure provider) a mechanism for the transmission of vocal communication between two parties ...

...bugger that, bugger the wolves, I'll just walk through the deep dark woods.

yours, in the hope that in 2008 we can talk with the "customers" better (or at least better - like )
bruce




(1) Shaddup Paolo, I DO know what his name is
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: «Midnight» on December 06, 2007, 08:28:24 am
Quote
...

"I just want to make a phone call"  
"What's a phone call"
"I just want to talk to Grandma"
"So, you want us to build a device, that will, given the incumbent Government develops the necessary infrastructure, legislates and empowers the defined demographic to intitiate and maintain (until such times as the medium is disconnected by either party, such parties including the initiator, the recipient and the infrastructure provider) a mechanism for the transmission of vocal communication between two parties ...

...bugger that, bugger the wolves, I'll just walk through the deep dark woods.

...

Of course, today's enlightened answer might be:

"Oh, now I see. You need a map!"

Likely followed by:

"We don't do that here, but there's someone who does."
"No, I don't know the address, but I can tell you how to get there. Starting from Grandma's house, you go..."

I agree with bruce et al. But please remember that a good use case is not enough. Context too is important.

Just adding my 0.02 CAD, rapidly eroding in value.

David
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: HydraKeven on December 06, 2007, 11:19:12 am
Quote
I suppose, all I'm trying to say is, for the sake of your own sanity, consider why documentation has failed this craft before.
 
To me it's not because it was not well structured.  Further, I have read through ALL of the last three pages looking (yet again) for "good ideas". Yet I am still not convinced that the "structured analysis" approach is feasible. Every day that work I see trade offs, concessions, bitter and sometimes "better" arguments about ....  


While we are straying quite confidently from the topic, I'll make the point that we are dealing with a double edged sword.  The reason that the industry adopted structured approaches was because of the utter failure of unstructured approaches.  Does any one remember the time before the UML and why all the competing methodologies came about?  And why the UML was formed between three competing, overlapping, popular methods.  And why structured documentation by various agencies was developed and refined?

While structured approaches have their problems, the alternative is quite unacceptable.  The challenge is using a structured approach effectively.  It needs to be flexible for the project's scale and purpose (and I believe, Bruce, this is the real problem).  In this respect, I do appreciate the anecdotal "projects" presented.

The people using it also need to be able to communicate effectively.  If you've been following the educational trends, the demand for better communication skills by industry and government has changed curricula across the world.  Also, consider the time it takes for a new employee to understand a project with and without structure.  What about accountability?  I could go on (and I have).  No, I don't believe abandoning the "structured approach" way of doing things is a viable solution.

So, if all you want to do is string two cans between your's and grandma's house, your structured approach should be scaled way down to fit the need, not the other way around.  If you want to use electric wiring and cell towers, it should scale up.  If you want to use existing tech, it might even scale down further:

Customer:  "I just want to make a phone call"
Requirement: "User must make a phone call."
Design: "Use existing phone to make phone call.  See existing phone documentation."
Implementation: "Educate user to pickup the phone and make phone calls."
Test: "Check that phone works as per phone documentation."

Parents do this with their children all the time.  Just because some of these things are obvious doesn't mean they are not done.  They are just not done in a formal manner.

Many people skip the idea of requirements because of the "obvious" nature many of them represent.  The mind tends to realize the requirement and dismiss it immediately as the (design) solution forms.  We are trained like this from infancy.  But, when we are dealing with particularly hairy problems, the solutions are not as obvious.  We think though what the problem's parts need.  By breaking down a problem, we get back to familiar territory, see the need (requirement) and form the solution (design).  Again, the "need -> solution" process is fairly instantaneous in our minds.  Why we get stuck on problems is due to the unclear nature of the needs for the problem.

Problem: How do I make an anti-gravity machine?
Need: An understanding of how the gravitational energy for the force is generated and can be manipulated.
Solution: Currently, none exists.
Why: We know that gravity (force) exists, but nothing about its energy's source (i.e. some hypotheses, nothing testable).

Hopefully, I successfully redirected back to structured requirements and design for SE (but not entirely back to IEEE SRS and SDD). :)
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: Paolo F Cantoni on December 06, 2007, 02:26:33 pm
Quote
Many people skip the idea of requirements because of the "obvious" nature many of them represent.  The mind tends to realize the requirement and dismiss it immediately as the (design) solution forms.  We are trained like this from infancy.
Experience, of course, shows that the "bleeding obvious" - isn't...

What's more we don't challenge that we actually do have a common undersanding...

:(

Paolo
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: thomaskilian on December 07, 2007, 01:23:43 am
My truth is rarely my customers truth. It always needs cycles to have a common understanding. Documenting these cycles helps reducing their numbers. Having a good blueprint is desirable but unlikely to have. A bad blueprint with history is almost the best you ever can get. Using UML (tools like EA) the right way improves the cycle process enormously. It took me several years to elaborate a nice way to document my projects effectively (!) with EA. If I had the time (and talent) I should write a book. Unfortunately I'm not DeMarco :'(
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: ukmtk on December 07, 2007, 02:41:58 am
I suspect that some ideas of how you go about using EA effectively may be appreciated by newbies.

If you are not able to provide a brief (long!?) howto then some pointers as to how you arrived at your enlightened state would be appreciated. I.e. books, papers, courses or even just experiences.
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: thomaskilian on December 07, 2007, 04:18:55 am
The problem is: this is a long story and I'm short of time since a longer period. You could hire me for such consultancy but I'm fully booked. I just can spend the time to answer a few questions on this board.
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: Paolo F Cantoni on December 07, 2007, 05:06:01 am
Quote
If you are not able to provide a brief (long!?) how to then some pointers as to how you arrived at your enlightened state would be appreciated. I.e. books, papers, courses or even just experiences.
If you mean the EA guru state, I got mine by reporting bugs...  Each post counts toward your status...  ;)

It's amazing how quickly you can find bugs in EA and accumulate Guru status... I hold a number of records...  Most bugs reported by a single user.  Most bugs reported in a single day.  Most bugs found and reported inside 1 hour (6).  ::)

HTH,
Paolo
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: sargasso on December 07, 2007, 07:51:21 am
... most consistent, insistent and obsistent use of the abstruse concept merynominomy (whatever)  ;D

bruce
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: Paolo F Cantoni on December 07, 2007, 02:16:43 pm
Quote
... most consistent, insistent and obsistent use of the abstruse concept merynominomy (whatever)  ;D

bruce
Meronymy is passe.... I've recently discovered connascence!  The interrelationship of coupling and cohesion!  8)

Came across it in: "What every programmer should know about object oriented-design" by Meiler Page-Jones.  From it's title you can see it wasn't published yesterday...

Paolo
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: jeshaw2 on December 07, 2007, 02:49:20 pm
Quote
connascence occurs between two software components when ...
  • It is possible to postulate that some change in one component requires a change in the other component to preserve overall correctness.
  • It is possible to postulate some change that require both components to change together to preserve overall correctness.
from this source (http://onestepback.org/articles/connascence/softwareconnascence.html)

Sounds like the o'le tightly coupled dragon again.  :-/

I need enlightenment I think 'cause Paolo knows better.  ;D

-Jim
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: sargasso on December 10, 2007, 02:43:35 am
Quote
[L. con- + nascentia birth, fr. nascens, p. pr. of nasci to be born.]

1. The common birth of two or more at the same tome; production of two or more together. Johnson.

2. That which is born or produced with another.

3. The act of growing together. [Obs.] Wiseman.


Ya know, I kinda like it.

Sort of like the product and the specification are developed at the same time.  Like the idea and the reality mature together and synergistically.

Prob'ly be a good idea for a methodology  ???  :o

Arrh, someone will probably come up with that sometime.



as ever, cynically yours
bruce
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: skiwi on October 27, 2010, 08:07:42 am
Bump.
Perhaps the 'EA wiki' could be the Community site.
Title: Re: Software Engineering Standards - IEEE SRS SDD
Post by: DanG83616 on October 28, 2010, 05:24:31 pm
Thanks for the bump.

Near the end there was discussion about how structured techniques failed in the past. I have been working on the idea that they failed due to inadequate specification technology.

Products implemented with software can be very much more complex  than products implemented with hardware. Software devices are not subject to constraints so concisely defined by the laws of physics (f=ma, v=ir, ...). The lack of constraints frees us to make really complex things. It is not that software makes things more complex; rather, it is that we can do more complex things with software.

The greater complexity requires greater ability to specify. We simply not up to the task with the tools and experience we had back in the 70's. When complexity exceeds ability to specify it we can use artists and craftsmen to do the building. They don't always get it right but often enough it is close enough and sometime some of them can actually get it right. Agile methodology is a really good way of getting the very most out of a artisan/craftsman workforce.

Improved ability to specify (describe that which does not exist such that it can be made to exist) improves productivity. The cost of attaining that ability and practicing it have to be economical compared to the artisan/craftsman method. Currently the artisan/craftsman method is economical for all but the most safety critical systems. Those  systems are the ones where close enough or occasionally right production is not economical.

I do not know what will change the economics. It might be that we discover new laws of physics that apply to software devices. Without the scientific discovery that occurred in the 19th century we would not have had the industrial revolution. Those latent laws might provide the constraints that we now unknowingly violate and build systems that fail. In the mean time, we can work on optimizing our ability to specify software more efficiently without them.

The UML and tools like EA improve specification efficiency. The UML provides the means to express aspects of software devices more concisely than we had back in the 70's. Tools like EA provide an economical way to organize and maintain those expressions. Standardizing the organization of them as in the IEEE standards would provide a baseline from which to start incremental improvement.

Having said all of that, I think the user community has to learn to utilize and improve the standards. I don't know that Sparx can do anything to specifically address Keven's suggestion.

Oh, and where is the EA wiki?

Dan