Author Topic: Software Engineering Standards - IEEE SRS SDD  (Read 10842 times)

HydraKeven

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
  • Personal Text!  All my posts are personal text...
    • View Profile
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #15 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.
« Last Edit: November 26, 2007, 10:13:02 am by HydraKeven »

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5882
  • Karma: +71/-79
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #16 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


Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

HydraKeven

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
  • Personal Text!  All my posts are personal text...
    • View Profile
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #17 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.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5882
  • Karma: +71/-79
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #18 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] 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!


« Last Edit: November 26, 2007, 11:55:38 am by PaoloFCantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5882
  • Karma: +71/-79
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #19 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)
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5882
  • Karma: +71/-79
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #20 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
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

HydraKeven

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
  • Personal Text!  All my posts are personal text...
    • View Profile
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #21 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.

KP

  • EA Administrator
  • EA Expert
  • *****
  • Posts: 2436
  • Karma: +29/-2
    • View Profile
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #22 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.
« Last Edit: November 26, 2007, 04:48:52 pm by KP »
The Sparx Team
support@sparxsystems.com

HydraKeven

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
  • Personal Text!  All my posts are personal text...
    • View Profile
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #23 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.
« Last Edit: November 26, 2007, 06:48:41 pm by HydraKeven »

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5882
  • Karma: +71/-79
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #24 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
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

thomaskilian

  • Guest
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #25 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 :(

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #26 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.
Verbal Use Cases aren't worth the paper they are written upon.

HydraKeven

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
  • Personal Text!  All my posts are personal text...
    • View Profile
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #27 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.

thomaskilian

  • Guest
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #28 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?

sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Re: Software Engineering Standards - IEEE SRS SDD
« Reply #29 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
« Last Edit: November 29, 2007, 12:43:55 am by sargasso »
"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.