Not Signed-In
Which clippings match 'Requirements' keyword pg.1 of 1
28 JUNE 2012

SEQ Legal: website law

"Web developers and webmasters need to ensure that their sites comply with the varied and ever–changing requirements of English law. Although it is relatively simple to create and publish a website, the legal consequences of those simple acts can be complex – and potentially expensive. A myriad of different UK and EU laws intrude upon website design, domain name choice, website content, sales from websites, and indeed every other aspect of ecommerce and online activity."

(SEQ Legal LLP.)



binding agreementcontractdesign businessdesign contract • domain name choice • e-commerce • ecommerce • English law • EU • EU law • intellectual propertylaw • legal consequences • legal services • online activity • professional practiceproject workrequirementssales • SEQ Legal • terms and conditionsUK • UK law • Web developers • webmasters • website • website content • website design • website law • websites


Simon Perkins
14 APRIL 2011

Scrum and Extreme Programming: User Stories

"User stories are one of the primary development artifacts for Scrum and Extreme Programming (XP) project teams. A user story is a very high–level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it."

(Scott W. Ambler, 2009)

Fig.1 User story card (informal, high level).

Fig.2 User story card (formal, high level).




Simon Perkins
14 APRIL 2011

UML Sequence Diagrams and detailed Object-Oriented Design

"If you figure that preliminary design is all about discovery of classes (aka object discovery), then detailed design is, by contrast, about allocating behavior (aka behavior allocation) – that is, allocating the software functions you've identified into the set of classes you discovered during preliminary design.

When you draw sequence diagrams, you're taking another sweep through the preliminary design, adding in detail.

With preliminary design, you made some informal first guesses at how the classes will interact with each other. Now it's time to make those statements very precise, to turn them into a detailed design that works within the Technical Architecture that you've defined.

You use sequence diagrams to drive the detailed design. But note that we advocate drawing your sequence diagrams in a minimal, quite specific format (which we describe fully in this chapter). There's a direct link between each use case, its robustness diagram, and the sequence diagrams. Just as you drew one robustness diagram per use case, you'll also draw one sequence diagram per use case.


UML 2.0 allows you to draw full–blown flowcharts on your sequence diagrams. However, even though the notation supports it, we consider the practice of drawing flowcharts on sequence diagrams to be inadvisable, because it puts emphasis on the wrong part of the problem.

In large part this is because drawing flowcharts simply misses the point of what you should be thinking about when you draw a sequence diagram. If you're trying to drive a software design from use cases, it's vitally important to get the allocation of operations to classes correct. This allocation of operations to classes tends to be a make–or–break design issue.

In the ICONIX Process, the primary purpose of the sequence diagram is to make this behavior allocation visible so that you get it right. If your mind is on drawing a flowchart, it's not going to be focused on this critically important set of behavior allocation decisions.

Once you've finished all the sequence diagrams for the use cases you're working on in the current release and updated your static model (class diagrams), you need to perform a Critical Design Review (CDR). The CDR forms something of a reality check for your design. We illustrate how to perform effective design reviews in our Use Case Driven book. Once the CDR is done, the implementation stage (coding and unit testing) begins."

(Doug Rosenberg and Matt Stephens, 2007)

Doug Rosenberg and Matt Stephens (2007) 'Use Case Driven Object Modeling with UML – Theory and Practice', Apress

Fig.1 sequence diagram notation.



activity diagrams • agile modellingarchitectureblueprintchart • collaboration diagrams • design • detailed design • diagram • Doug Rosenberg • dynamic behaviour • dynamic view • enterprise architect • eXtreme Programming • Grady Booch • ICONIX • information design • Ivar Jacobson • James Rumbaugh • Matt Stephens • MDG • model driven generation technologies • modelling languagenotation • Object Management Group • object oriented analysis • object-oriented design • object-oriented software • OML • OMT • OOAOOD • OOSE • preliminary design • product designrequirements • sequence diagram • softwaresoftware architecture • static view • structural view • technical architecturetechnologyUMLUnified Modelling Languageusage scenariosuse casesvisual languagevisualisation


Simon Perkins
28 MARCH 2011

The top 10 major benefits of high-fidelity prototyping

"1) First and foremost, a high–fidelity prototype gives you something realistic enough to try out your ideas with target users and customers before making a significant investment. This lets you discover which ideas are good and which are not, and if the product has real value, and also discover if users can figure out how to use the product.

2) Doing a high–fidelity prototype helps you – even forces you – to think through your product to a much greater degree than paper specs.

3) A high–fidelity prototype enables and encourages the type of collaboration between product manager, interaction designer, and architect/engineer that is necessary to discover a valuable, useful and feasible product.

4) A high–fidelity prototype provides the level of information necessary for accurate engineering cost estimates, early in the process when these estimates are most useful.

5) A high–fidelity prototype provides the engineers and QA organization with a rich, interactive description of the product's intended functionality and design to be used as a reference basis for implementation and test.

6) A high–fidelity prototype provides the rest of the organization – marketing, sales, customer service, business development, company execs – with a useful understanding of the product to come early enough in the process that they have time to do their jobs properly.

7) A high–fidelity prototype prevents the classic waterfall problem of doing design after the requirements, rather than realizing that functionality and user experience are inherently intertwined.

8) If you do a high–fidelity prototype and you test your ideas with users and you find significant problems, you will have saved your company the cost in terms of time and money of building something that would have failed. Not to mention the opportunity cost of what the team could have been building.

9) If you do a high–fidelity prototype and validate this with target users, you will significantly reduce the time it takes for your developers to build the product both because the product is better defined, and also because you will have been forced to resolve many of the questions early that otherwise throw a wrench into development.

10) A high–fidelity prototype helps keep the focus of the team on the user experience."

(Marty Cagan, 29 April 2008)



Simon Perkins
06 NOVEMBER 2008

The Waterfall Versus Whirlpool Project Management Methods

"'Whirlpool' projects embrace the fact that requirements are volatile. Instead of trying to deliver a system that satisfies 100% of the requirements in one go, the focus is on delivering an agreed subset of the requirements at intervals. Use cases are the building blocks of requirements and provide a convenient basis for risk assessment and prioritising. The riskiest and most significant use cases are tackled first, within the context of a clearly understood architectural vision. Tackling risk early identifies problems before they become too expensive or threatening, and helps lead to more stable architectures. The system evolves as a sequence of increments, each one an enhancement to the already–delivered functionality.

The development process for each increment is founded on the idea of a workflow, consisting of activities. For example. instead of having an analysis stage followed by a design stage, a worker might be engaged in analysis activities and design activities, depending on the job in hand. It is important to recognise that analysis activities focus on the problem space, while design activities focus on the solution space. A good understanding of one part of the problem may well lead to faster progress to design in that area. It is also possible that design activities highlight shortcoming in the analysis or even the requirements, in which case these are amended to reflect the newer (and hopefully better) understanding.

Successive iterations converge on a more complete, correct and consistent model, leading ultimately to implementation and delivery."



agile developmentconcurrent engineering (CE)developmentdevelopment life cycleincremental • iterative • objectives • PRINCE2 • projectproject managementproject management methodrequirementsrisksoftware development lifecycle • stable • Unified Process • use case • volatile • waterfall modelwhirlpool modelworkflow


Simon Perkins

to Folksonomy

Can't access your account?

New to Folksonomy?

Sign-Up or learn more.