OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm] Use Case 2.0 article


Ken-- I noticed the access to SME thing, too. I concluded it was a nod to the Agile perspective that implies you have frequent on-going access to your requirements-givers (not technology SME's I am thinking, but business SME's.)  The more traditional SE models assume, I would say, relatively little access to authoritative requirements-givers, so the interactions are planned to be more formal and less frequent. 

I think there's also an element of how much requirements change the process can and wants to deal with. Agile emphasizes flexibility and assumes that forces driving requirements (the market, competition, available technology) are very rapidly changing and must be accommodated. My own experience is that the type of business SME one often gets on an on-going basis is a lower-level, operator type person who is perhaps less sensitive to the strategic constraints on a project (cost, compatibility with other enterprise or partner systems, etc.) that the business owners. Thus the "requirements" these folks come up with often result in scope (and cost) creep without strategic benefit. 

But the agile approach has its place, and maybe even its the biggest place, where time to market is critical, requirements change frequently and the customers will tolerate late-beta problems as long as the fix comes along pretty quickly. 

Martin
.  

On Wed, Mar 8, 2017 at 3:12 PM, Ken Laskey <klaskey@mitre.org> wrote:
Luckily, MITRE has a CACM subscription.  

I found the Principles for Use-Case Adoption to be to the point:
1. Keep it simple by telling stories
2. Understand the big picture
3. Focus on value
4. Build the system in slices
5. Deliver the system in increments
6. Adapt to meet the team’s needs.

The titles are good enough even without the associated text.

To the point of user stories vs. use cases, I don’t see how one get a quality use case without the SME or why the SME is more critical the the user story.  I think we’ve all seen the situation where the requirements, in whatever form captured, is a contract deliverable and the staff compiling the requirements has to generate paper from whatever knowledge base they can bring to bear.  If anything, the goal should be to keep the error consequences low so we can remediate when we find the requirements — user stories or use cases/slices — are lacking.

Ken

------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510          phone: 703-983-7934
7515 Colshire Drive                           fax: 703-983-1379
McLean VA 22102-7508

On Mar 3, 2017, at 12:44 AM, Martin Smith <bfc.mclean@gmail.com> wrote:

At this week's TC meeting I mention this article from the May 2016 issue of the Communicatons of the ACM. 

The particular point I mentioned was a conclusion about when to use light-weight (agile) requirements methodologies (using "stories" as the _expression_ of requirements) vs more formal requirements approaches (using "use-cases" to express requirements.) I thought the same consideration might apply to the whole devops/MSA approach vs. more traditional SDLC approaches. Here's what the article said: 

" The question remains: Which technique should you use that is very context dependent, once you go beyond personal preferences? Consider the following factors: how much access is there to the SMEs (subject matter experts); and how severe will requirements errors be if they escape to a live environment.

The sweet spot for user stories is achieved when there is easy access to a SME and the severity of errors is low. Use cases and use-case slices are more suitable when there is no easy access to a SME or when error consequences are high.  "

The full article is pretting interesting, too, but access to it requires an ACM membership or subscription to CACM. Here's the link to the abstract and to the full article  in case you are an ACM member or wish to be one!



Regards,

Martin


--
Martin F Smith, Principal
BFC Consulting, LLC
McLean, Va 22102




--
Martin F Smith, Principal
BFC Consulting, LLC
McLean, Va 22102
703 506-0159
703 389-3224 mobile


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]