Hi Scott,
Abstract or low-fidelity UI prototyping
seems to be more of a design activity. As soon as you say “Here’s a
form with a button…” you’ve done some abstract design. This
type of prototyping seems analogous to an analysis model. That is, it’s a
conceptual model that supports a lot of reasoning without going through the work
of detailed design.
The distinction between this and a
usability requirement is that it’s testable without describing any
implementation or solution. For example:
Exact-match search results are visible without
any post-search interaction from the user.
Inexperienced users shall be able to enter
customer search criteria in less than 10 seconds, on average.
The kind of low-fidelity prototyping you
describe in your link is extremely useful. It’s just the kind of
guideline we should be adding to BUP to help developers do a better job
creating their UIs.
- Jim
____________________
Jim Ruehlin, IBM Rational
RUP Content Developer
Eclipse Process Framework (EPF) Committer
email: jruehlin@xxxxxxxxxx
phone: 760.505.3232
fax:
949.369.0720
From:
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of "Scott W. Ambler"
<swa@xxxxxxxxxxxx>
Sent: Wednesday, April 05, 2006
3:36 AM
To: Eclipse Process Framework
Project Developers List <epf-dev@xxxxxxxxxxx>
Subject: RE: [epf-dev] Overarching
considerations (was: Status from3/30 BUPcall with authors)
At 08:47 PM 4/4/2006, you wrote:
>Hi Chris,
>
>I’d put most of usability into the “design”
>category, although a very different type of
>design than software design. We might have
>usability requirements that state that we need
>to conform to some accessibility standard, but
>the UI design would describe how the UI should
>be implemented to accomplish that. I’d like to
>treat the UI prototype is a UI design artifact
>rather than a requirement. Unless, as you said,
>we want to constrain the UI implementation.
What about the concept of abstract/lo-fidelity UI
prototyping for requirements activities? See
http://www.agilemodeling.com/artifacts/essentialUI.htm
- Scott
>
>- Jim
>
>____________________
>Jim Ruehlin, IBM Rational
>RUP Content Developer
>Eclipse Process Framework (EPF) Committer
>email: jruehlin@xxxxxxxxxx
>phone: 760.505.3232
>fax: 949.369.0720
>
>
>From: epf-dev-bounces@xxxxxxxxxxx
>[mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf
>Of "Chris Sibbald"
>Sent: Tuesday, April 04, 2006 12:44 PM
>To: "Eclipse Process Framework Project Developers List"
>Cc: External Chris Sibbald
>Subject: RE: [epf-dev] Overarching
>considerations (was: Status from3/30 BUPcall with authors)
>
>Hi Ricardo,
>
>There is actually a fairly widely accepted
>requirement sub-type known as an “Interface
>Requirement”. (Remember the “+” in FURPS+).
>
>In my previous email I was referring to external
>interfaces to other systems (not the UI).
>
>Although one could consider the UI as an
>interface requirement, I wouldn’t think of it
>that way since this immediately places a
>constraint on development so it’s probably
>better to have some wiggle room and call it a
>prototype vs. an interface requirement. Once
>you call it a requirement expectations are set
>accordingly. (Note that there may very well be
>valid constraints on the UI, such as
>accessibility requirements which should be captured and verified).
>
>As I said I will defer GUI
>architecture/prototype to the experts 8-). We
>do currently have an artifact for the ui_prototype in BUP.
>
>Cheers,
>Chris
>
>
>From: epf-dev-bounces@xxxxxxxxxxx
>[mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Ricardo Balduino
>Sent: Tuesday, April 04, 2006 2:49 PM
>To: Eclipse Process Framework Project Developers List
>Subject: RE: [epf-dev] Overarching
>considerations (was: Status from3/30 BUPcall with authors)
>
>
>Chris,
>
>Considering that Supporting Requirements capture
>the 'FURPS' (Functional, Usability, Reliability,
>Performance and Supportability) requirements
>(did I spell it right? :-), then interface
>related requirements would be captured in the
>'U' section of this artifact. These and
>storyboards (plus UI prototype) should cover
>what is needed in terms of UI. The thing is we
>don't have storyboards as an artifact. Should we
>consider a guideline for that?
>
>Would business rules fit on the 'F' section of
>the Supporting Requirements' artifact?
>
>Cheers,
>
>Ricardo Balduino
>
>"Chris Sibbald"
>Sent by: epf-dev-bounces@xxxxxxxxxxx
>
>04/04/2006 11:11 AM
>Please respond to
>Eclipse Process Framework Project Developers List
>
>To
>"Eclipse Process Framework Project Developers List"
>cc
>External Chris Sibbald
>Subject
>RE: [epf-dev] Overarching considerations (was:
>Status from 3/30 BUPcall with authors)
>
>
>
>
>
>
>Hi Folks,
>
>My $.02:
>
>Glossary: I think in the majority of cases this
>is a must to ensure everyone is speaking the
>same language. I don’t think there will be too
>much pushback by including it as an optional
>artifact, to be included depending upon the
>knowledge of the team with the application
>domain. Where to put it, RM domain?
>
>GUI architecture: defer to the experts 8-)
>
>Interface requirements: absolutely essential in
>my humble opinion, but could easily be a section
>of the supporting requirements (since they are constraints).
>
>Business Rules: hmmm. I think Use Case and
>supporting requirements should be able to capture the business rules.
>
>Data Modeling: defer to the experts.
>
>Deployment: I think we should include this in
>BUP, timing will depend upon priorities and available time.
>
>Cheers,
>Chris
>
>
>
>
>From: epf-dev-bounces@xxxxxxxxxxx
>[mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Ricardo Balduino
>Sent: Tuesday, April 04, 2006 2:01 PM
>To: Eclipse Process Framework Project Developers List
>Subject: [epf-dev] Overarching considerations
>(was: Status from 3/30 BUPcall with authors)
>
>
>Ana
>
>Thank you for your observations.
>I think these are good points to discuss with
>each subgroup (or discipline owners) as pointed
>in the email below. You may want to join these
>groups or interact with the listed owners.
>
>In a nutshell, the discussion should be around:
>
>- if glossary and rules have to be captured, are
>they worth of having their own artifact or being
>in a section inside the Vision? The former
>increases number of artifacts in BUP (do we
>desire that?) as where as the later, although
>seems to preserve the number of artifacts, may
>cause the Vision doc to be cluttered.
>
>- GUI architecture: we may consider a guideline
>explaining how to address these concerns. Is
>this something you would like to contribute to
>by writing such guideline, in case we decide to cover it?
>
>- Interface with external systems: these systems
>(who) should be captured and described as actors
>in the Use Case model. Any further description
>in terms of types of interaction (what) is
>expected with these systems could be seen as
>Supporting Requirement and captured in such
>artifact. But we may need to revisit
>architecture/development tasks to eventually
>include step or guidance (how) to develop interfaces to such systems.
>
>- Data modeling hasn't been discussed to be in
>BUP (yet, as far as I remember). Could it be in a plug-in later?
>
>- Deployment: we've been postponing a more
>serious consideration of that discipline in BUP.
>My take is that we should cover the essentials
>of it, and your suggestions below seem adequate.
>Now it's a decision on if we include it in
>release 1.0 in September or later. I see it in
>core BUP though, not as a plug-in. If we decide
>for having it, would you be willing to add content on that?
>
>Comments anyone?
>
>Cheers,
>
>Ricardo Balduino
>IBM | EPF Committer
>Ana Valente Pereira
>Sent by: epf-dev-bounces@xxxxxxxxxxx
>
>04/02/2006 04:39 AM
>
>
>Please respond to
>Eclipse Process Framework Project Developers List
>
>
>To
>Eclipse Process Framework Project Developers List
>cc
>
>Subject
>Re: [epf-dev] Status from 3/30 BUP call with authors
>
>
>
>
>
>
>
>
>
>
>
>Sorry for this long mail but I will have no access to the internet for
>the next 2 weeks and I wont be able to attend the next conference
call….
>so I will try to resume all my content authoring ideas for contributing
>to BUP 1.0 here… you can move to bugzilla what you agree to add and I
>will pick up work when I come back
>
>As I told in Bilbao meeting, my experience with the RUP comes from
>several years of “small projects “ (teams of 3 to 6 people and
involve 3
>to 6 months of development effort) … and there are some good
practices
>that I would like to see in BUP, even in small projects, otherwise I
>believe there will be a lot of plug-ins to BUP adding these basic things:
>
>Requirements:
>
>... vision and use cases are not enough in requirements ...even in small
>projects:
>
>1) Glossary: if you don’t define project domain terms somewhere the
>definition will end-up mixed with the use cases… when needed we also
add
>a simple domain model to the glossary (this is not big upfront
>design…see (http://www.agiledata.org/essays/agileDataModeling.html)
…
>and sometimes stakeholders express their requirements in these terms
>more easily than in use cases (I want a shopping cart) … can we add a
>Glossary to BUP?… or at least a chapter to the Vision?
>
>2) Rules: the same for business rules: separate business rules out of
>use cases… rules are also requirements that can developed separately
…
>if they are spread out on use cases they will end up spread out in the
>code… can we add a Rule Catalog artifact to BUP or a specific section
on
>the Supporting Requirements? (I am quoting Scott Ambler again but I know
>that he is reading this email list
>http://www.agilemodeling.com/artifacts/businessRule.htm) … sometimes
>stakeholders don’t care much about reading use cases but they do care
>about getting business rules definition right
>
>Architecture
>
>… get stakeholders involved in the architecture (at the system
boundaries)
>
>1) GUI Architecture - If we let the developers pick up scenarios and
>implement them without some kind of user interface guidelines and global
>mechanisms (menus structure,, navigation map … etc) the GUI will be a
>mess … even with the prototype … I think that it is missing
some kind of
>user Interface structuring and guidance … can we add these
>responsibility to the architect or analyst?...and discuss it with the
>stakeholder along with the prototype?
>
>2) Interface with external Systems – more and more we have to develop
>code for systems where the actor is not a person but another system. The
>architect should identify these communication interfaces and discuss
>them with the stakeholders responsible for those systems …because
>usually external systems have to be modified to use the services we are
>providing (or vice-versa) this is not a bit discussion on SOA (the
>interface can be a file or a stored procedure, for instance) …but it
can
>lay out the foundation for a SOA plug-in to BUP latter … this is part
of
>the architecture but we can’t put in on Software Architecture
Document
>because stakeholders usually don’t read these document … but
they need
>it…I think that we also need a step on Task: Analyze the Architecture
on
>this subject (identify external services?)
>
>3) There is nothing on Data Modeling on BUP? (even agile?)
>
>Deployment…there is no deployment discipline? What is the purpose of
>making the software if it is not for deploying? …what is the purpose
of
>Transition Phase in BUP ? it does not have to be a lot of content … I
>propose that we consider the minimum:
>
>1) If we have a Build work product on Implementation I would add a
>“Release” work product on deployment with some System
Requirements,
>Installation Instructions and known issues … we have an example on
>(http://www.eclipse.org/epf/downloads/downloads.php) …and add a task
for
>Create Release
>
>
>best regards
>
>Ana Pereira
>
>
>
>
>Brian Lyons wrote:
>
> > hiho,
> >
> > On Thursday, 3/30 at 8am PST, there was a conference call on
assigning
> > ownership to BUP content as we modify and complete the IBM donation
> > for the 1.0 launch scheduled for 9/1/2006.
> >
> > On the call were:
> >
> > · Steve Adolph, UBC
> >
> > · Ricardo Balduino, IBM
> >
> > · Mark Dickson, Xansas/DSDM Consortium
> >
> > · Chris Doyle, Synergy Plus
> >
> > · Brian Lyons, Number Six Software, Inc.
> >
> > · Bruce MacIsaac, IBM
> >
> > · Jim Ruehl, IBM
> >
> > · Chris Sibbald, Telelogic
> >
> > We decided to have each content package in BUP assigned to a
committer
> > (or – based on duration it is taking – someone on track
to be a
> > committer). We discussed that the templates package is not really a
> > logical separate area, but only broken out for convenience of process
> > engineers; each template would be the responsibility of the owner of
> > the relevant discipline. In this pass the Process is not the focus.
> >
> > The assignment of a package does not imply that the individual is
> > solely responsible for authoring all the content. The assignment of
> > the package is responsibility that the content gets authored.
> >
> > Based on the participants on the call, the responsible parties are
> > shown below. One addition is that we have a pending decision on
> > project management because Kirti Vaidya had proclaimed an interest in
> > that, but was not on the call.
> >
> > *Package*
> >
> >
> >
> > *Owner*
> >
> > architecture
> >
> >
> >
> > Chris Dickson, Xansas
> >
> > change_management
> >
> >
> >
> >
> >
> > development
> >
> >
> >
> >
> >
> > general
> >
> >
> >
> > Steve Adolph, UBC
> >
> > project_management
> >
> >
> >
> > Kirti Vaidya, Covansys (pending)
> >
> > requirements
> >
> >
> >
> > Chris Sibbald, Telelogic
> >
> > test
> >
> >
> >
> > Brian Lyons, Number Six Software
> >
> > Ricardo Balduino of IBM will manage the overall architecture of the
> > process. Based on the way EPF Composer works, Ricardo will be
> > responsible for managing all relationships between elements. And he
is
> > responsible for creating any additional elements that will
> > subsequently be assigned to reside in a package.
> >
> > If you are a committer or on your way to becoming one and you have an
> > interest in being responsible for cm or development, please reply.
> >
> > Everyone interested in contributing content should be getting Eclipse
> > setup for CVS to access BUP. That is the best way to get the most
> > up-to-date content. This is the real-time development repository that
> > committers check their work into. Official committers have read-write
> > access, but anyone can use it to regularly pull the very latest
content.
> >
> > There will be a conference call on Thursday, 4/6 at 8am PST to
discuss
> > updates and status of this work. We have a milestone on 4/15 to be
> > underway with authoring content and have all elements defined (albeit
> > possibly incomplete). As the various guidelines are often driven by
> > the detail in the other process elements, we are giving ourselves
some
> > leeway in not strictly baselining those by that date.
> >
> > ------------ b
> >
>
>------------------------------------------------------------------------
> >
> >_______________________________________________
> >epf-dev mailing list
> >epf-dev@xxxxxxxxxxx
> >https://dev.eclipse.org/mailman/listinfo/epf-dev
> >
> >
>_______________________________________________
>epf-dev mailing list
>epf-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/epf-dev
>
>
>
>--------------------------------------------------------------------------------
>Telelogic Lifecycle Solutions:
>Helping You Define, Design & Deliver Advanced Systems & Software
>Learn More at www.telelogic.com
>
>Chris Sibbald
>Vice President, Standards and Technology
>Telelogic North America Inc.
>255 Albert Street, Suite 600
>Ottawa
>Ontario K1P 6A9
>Canada
>
>Phone: +1 (613) 266 5061
>Fax: +1 (613) 482 4538
>Mobile phone: +1 (613) 266 5061
>
>Chris.Sibbald@xxxxxxxxxxxxx
>http://www.telelogic.com
>
>Telelogic - Requirements-Driven Innovation!
>-------------------------------------------------------------
>
>The information contained in this e-mail,
>including any attachment or enclosure, is
>intended only for the person or entity to which
>it is addressed and may contain confidential
>material. Any unauthorized use, review,
>retransmissions, dissemination, copying or other
>use of this information by persons or entities
>other than the intended recipient is prohibited.
>_______________________________________________
>epf-dev mailing list
>epf-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/epf-dev
>_______________________________________________
>epf-dev mailing list
>epf-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/epf-dev
>_______________________________________________
>epf-dev mailing list
>epf-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/epf-dev
====================================================
Scott W. Ambler :-)
Senior Consultant, Ambysoft Inc.
www.ambysoft.com/scottAmbler.html
Refactoring Databases: Evolutionary Database
Design (www.ambysoft.com/books/refactoringDatabases.html) is now available!
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
