1 / 29

Object-Oriented Software Engineering

Object-Oriented Software Engineering. Writing Requirements Paul J Krause. Credits. Most of this material has been reused from slides presented by Tom and Kai Gilb (with permission) See: http//:www.gilb.com. Why Requirements?.

idra
Télécharger la présentation

Object-Oriented Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Object-Oriented Software Engineering Writing Requirements Paul J Krause

  2. Credits • Most of this material has been reused from slides presented by Tom and Kai Gilb (with permission) • See: http//:www.gilb.com

  3. Why Requirements? “The firms improving their development speed at the fastest rate actually spend more elapsed time and more effort in the customer requirements stage of the project …. These firms spend significantly less time in the testing and integration stage of development.…” Blackburn, Scudder, et al, in Improving Speed and Productivity of Software Development: A Global Survey of Software Developers (1996) Resources spent on Customer Requirements:

  4. Planguage advances and differences over conventional requirements specification • Below are given some IEEE definitions of ‘Requirement’ • Requirement: • a condition or capability needed by a user to solve a problem or achieve an objective. <- [IEEE 610.12-1990] • Example of an IEEE definition of ‘requirement’. The term ‘user’ is probably not broad enough to capture the scope of all stakeholders. • Does not distinguish well enough from means/design • Requirements: • Statements, which identify the essential needs for a system in order for it to have value and utility. • Requirements may be derived or based upon interpretation of stated requirements to assist in providing a common understanding of the desired operational characteristics of a system. • <- IEEE P1220. IEEE Standard for Systems Engineering, Preliminary, 1993 in [SEI-95-MM-003]

  5. INTRO Tom on ‘Requirement’ • Requirement: Concept *026 November 8, 2001 22:16 • A requirement is a stakeholder-desired Target or Constraint. • Notes: • 1. The constraints can apply to an engineering process, a design or an operational system. • 2. A requirement is an input to a defined level of design process. • 3. Requirements give information to the designer about the necessary nature of their design. • 4. Consequently the design, specification or implementation, can be judged {Spec QC, review, test or in operation} in terms of how well it satisfies those requirements.

  6. Requirement Specification. • Requirement Specification. Concept *508. November 8, 2001 1604 • A requirement specification is the readable expression of a requirement and any requirement background. • Related Concepts: • requirement *026 the future state or constraint • specification *137 the readable artifact • background *507 additional information about the requirement

  7. Analysis of dangerous common requirements practices. • Mixing real requirements with ‘designs’ • Failing to quantify competitive qualities • Failing to derive implied requirements from designs • Failing to set requirements at appropriate level • Failing to include source information • Failing to include priority information • Failing to specify all critical stakeholders requirements • Failing to distinguish between wishes and their profit • Failing to consider all limited resources as requirements • Failure to update requirements evolutionarily • Failure to consider time, location and conditions with requirements • Failure to plan a time series of quality levels

  8. Planguage focus: Ends over means • Deming on true aims • “The aim must include plans for the future”<- [DEMING93, page 51] • “It is important that an aim never be defined in terms of activity or methods. It must always relate to how life is better for everyone.” <-[DEMING93, page 52] • “<- [DEMING93, page 52] Attributed to Deming by The aim precedes the organizational system and those that work in it. Workers, for example, can not be the source of the aim, for how would one know what kind of workers to choose?” Carolyn Bailey

  9. Planguage is about ‘Clarity’ • “For me, a hypothesis is • a statement whose truth is temporarily assumed, • but whose meaning must be beyond all doubt.” E = mc2 + … 1912 Special Theory of Relativity. (source data in slide note) Source: Calaprice p 235 see slide note for detail

  10. Stakeholders: requirements sources • ‘Stakeholders’ are: • Any person, group or thing which • Can determine our system’s degree of success or failure • By having an “opinion” about • system performance characteristics • system lifecycle constraints • Stakeholders determine requirements! • Systems engineers determine which requirements the stakeholders need • Even if the stakeholders are not currently conscious of those needs!

  11. Stakeholder: Concept *233 . ‘Stakeholders’ are: • Any person, group or thing • that can determine our systems degree of success or failure, • by having an opinion about •  system performance characteristics and • system lifecycle constraints

  12. Stakeholder Interests • For example they might have an interest in • Setting the objectives for a process. • Evaluating the quality of the product • Using the product or system, even indirectly • Avoiding problems for themselves as a result of our product or system. • Being compatible with another machine or software component. • Determining constraints on development, operation or retirement of the system.

  13. Performance Requirements: Qualities, Quantities, SavingsConstraints: Limits and Fences • Performance attributes can be viewed as: • Quantities (= Capacities) • Like {Space, Time, Money, Effort, Data}” How MUCH? • Qualities • ‘How well’ something is done; “-ilities” • Savings/Benefits/Improvements • A Quantity or Quality which is better than some defined benchmark alternative. • O-----<=====>------> • Levels-of-performance concepts • Performance-related concepts • Target view O------>-------> • The future-state requirement level > • Value O---->----> • Same as Target, but implies a stakeholder exists who ‘values’ that level. • Benchmarks O-------<--------> • One or more fact-based reference levels to compare targets with, and ascertain value • Change view O----<====>---> • The difference, or gap, between benchmarks and targets represents planned change. • Normally this represents a planned degree of ‘improvement’ • (but it can be any state, +, 0 and -).

  14. Performance Attributes Resources Qualities (How well) System Mission Capacities (How Much) Savings (How much resource saved) Performance.Capacity Model *459 Sept.5 2001 Work Capacity Responsiveness Storage Capacity Income Data

  15. Constraints: Binary and Scalar • Constraint: (Concept *218) September 7, 2001 • A constraint is a requirement specification that explicitly and intentionally restricts the engineering process, a systems operation, or its lifecycle. • There are two types of constraints: Binary and Scalar. • 0:1 Binary Constraints are statements like ‘must/must not’. These are called Demands (must) and Vetoes (must not). • -|-|- Scalar Constraints are specified using a Scale of measure, to limit some resource or capability in some way.

  16. Stakeholders • Why you have to identify them formally • How to find out and confirm their requirements • Example of classes of stakeholders • How to specify stakeholders together with their requirements.

  17. Stakeholders:Why you have to identify them formally • Stakeholders determine requirements! • If you don’t identify all ‘critical’ stakeholders • You probably cannot identify all critical requirements • If you don’t identify all critical requirements • You will get delays and problems and failures sooner or later • ? IF WE HAVE GOT THE REQUIREMENT DO WE THEN STILL NEED TO DOCUMENT THE STAKEHOLDERS CONCERNED?

  18. Stakeholders: How to find out and confirm their requirements 1. Identify all critical and profitable STAKE-HOLDERS 2. Identify All critical and profitable stakeholder REQUIRE-MENTS 4. Validate and agree these requirements with stakeholders 3. Detail and clarify requirements (Scale +Benchmarks+Targets) 5. Select most profitable requirements to deliver first (Evolutionary delivery) 6. Learn new requirements evolutionarily as result of experience feedback and time (new technology, markets and cost levels)

  19. Stakeholders: Example of classes of stakeholders;

  20. Stakeholders: How to specify stakeholders together with their requirements. • The Planguage parameter term ‘Stakeholder’ can be used to specify one or more stakeholders explicitly. • Internal Interests: Stakeholder = {End User, Help Desk, Installer} • We can attach stakeholder information to any elementary specification, • Usability: Scale: Time to learn a task for a defined [Stakeholder] • Goal [Stakeholder = Novice User] 10 minutes. • Novice User: Defined As: anyone without any training in this system or task. • or to a set of specifications, • Scale [Installers] time for successful installation • Fail 20 minutes, Goal 10 minutes, Wish 5 minutes. • as appropriate.

  21. PlanGUAGE Benchmarks: Past: any useful reference point. Your old product, a competitors organization, or a quality achieved in same discipline but different branch of business. Record: best in some class, state of the art. Something to beat. A challenge for you. An extreme Past. Trend: a future guess based on Past. ? Requirements (Targets & Constraints) Fail do: a level constraint needed for avoiding some pain, loss, discomfort Goal: the target level needed for satisfaction, happiness, joy and 100% full payment! ? Wish: a target level desired by someone, but which might not be feasible. Project is not committed to it. Stretch: a motivational target, but a difficult target + [ ] Survival: an extremely strong constraint level: Failure point

  22. 3.Requirements Specification Rules;Definition • Rule: Concept *129. September 3 2001 • A rule is an engineering work process standard for specification writing. • A rule should be a significant highly-recommended best practice. • Failing to follow a specification rule should arguably threaten system economics or product quality, • and rule violation is therefore classified as a ‘defect’ in the specification.

  23. 3. Requirements Specification Rules;Example, Part 1 of 7 • GEN.1 (Consistency) • Specifications must be consistent with all other related specifications in the same document, and in all related documents {Sources, Kin and Children}. • GEN.2 (Unambiguous) • All specifications must be unambiguous to the Intended Readership, as practiced or implied, for that document.

  24. 3.Requirements Specification Rules;Example, Part 2 of 7 • GEN.3 (Notes) • All manner of comment, notes, suggestion or ideas which are not themselves the actual engineering specification, but merely background, shall be clearly distinguished as such by suitable devices. • Suggested Devices: italics, ”double quotes”, Note:…, Comment:…., use of footnotes, use of separate commentary pages. • GEN.4 (Brevity) • All specification shall be as brief as possible, in order to successfully support their purpose, for the defined Intended Readership.

  25. 3. Requirements Specification Rules;Example, Part 3 of 7 • GEN.5 (Clarity of Purpose) • All specification shall result in clarity to the Intended Reader regarding it’s purpose or intent. • Note: it is not enough that the statements are unambiguous. They must contain clarity of purpose: why is this here? “Clear enough to test” • GEN.6 (Elementary) • Specification statements shall be broken up into their most elementary form. • Note: this is so that they each can be unambiguously cross-referenced externally. • Note: an elementary specification can be referred to by its tag (or global tag), and within that, any unique combination of Parameter (for example Meter, Past) and/or Qualified (for example ”[UK, 1999]” ) may be used to refer to or distinguish an elementary idea.

  26. 3.Requirements Specification Rules;Example, Part 4 of 7 • GEN.7 (Unique) • Specifications shall only have a single instance in the entire project documentation. • GEN.8 (ID Tags) • All specifications statements must have some unique and unambiguous cross-reference capability, which is stable (independent of sequence and changes). • Statements may be directly tagged. • Statements may be referenced by a hierarchy of tags • Statements may be referenced in detail using Parameter names (like Meter, Goal) and Qualified (like [Euro, 2001]) • References may have defined synonyms for convenience.

  27. 3. Requirements Specification Rules;Example, Part 5 of 7 • GEN.9 (Reuse) • Tagged Ideas shall be ’reused’ by cross-reference to their unique tag, or their tag and version information. • GEN.10 (Source) • Specifications shall contain detailed (paragraph, unique tag level) references about their exact and detailed sources. • Note use: ’Spec <- Source’ format or ’Source:……’

  28. 3. Requirements Specification Rules;Example, Part 6 of 7 • GEN.11 (Hierarchy) • Specifications shall be logically organized into a useful hierarchical structure. • The tagging system shall reflect that structure (example A.B.C) • Note: this may be partly done through templates. • GEN.12 (Auditability) • All changes to specifications shall be done in such a way as to permit us to know who changed things, what the previous version was, perhaps even justification for the change. • GEN.13 (Risk) • The specification Author must clearly indicate any information which is uncertain or poses any risk to the project whatsoever, using a variety of available devices such as {<fuzzy brackets>, ??, ?, ranges (60->70, 60±10%), suitable comments or notes}.

  29. 3. Requirements Specification Rules;Example, Part 7 of 7 • GEN.14 (Template) • The relevant electronic template shall be used, for specific headings and guidance under each heading. • GEN.15 (Model) • A ’best practice’ model shall be defined and available. It shall be used to help interpret the intent of these rules in practice. • Note: see extensive separate comments for justification of these Rules, tag C.GEN

More Related