By Topic

Software, IEEE

Issue 2 • Date March 1994

Filter Results

Displaying Results 1 - 12 of 12
  • Giving voice to requirements engineering

    Publication Year: 1994 , Page(s): 12 - 16
    Cited by:  Papers (9)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (846 KB)  

    Developers have plenty of reasons to avoid investing in requirements engineering: It is next to impossible to capture user needs completely, and needs are constantly evolving. The gap between software research and practice is no more evident than in the field of requirements engineering. Requirement engineering has a fairly narrow goal - determine a need and define the external behavior of a solution - but the range of research into requirements is enormous.<> View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Challenging universal truths of requirements engineering

    Publication Year: 1994 , Page(s): 18 - 19
    Cited by:  Papers (4)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (201 KB)  

    Requirements engineering is likely to be a major issue in this decade. The author examines two widely held beliefs: requirements describe a system's "what", not its "how". Requirements must be represented as abstractions.<> View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Inquiry-based requirements analysis

    Publication Year: 1994 , Page(s): 21 - 32
    Cited by:  Papers (102)  |  Patents (2)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1618 KB)  

    This approach emphasizes pinpointing where and when information needs occur; at its core is the inquiry cycle model, a structure for describing and supporting discussions about system requirements. The authors use a case study to describe the model's conversation metaphor, which follows analysis activities from requirements elicitation and documentation through refinement.<> View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Formal approach to scenario analysis

    Publication Year: 1994 , Page(s): 33 - 41
    Cited by:  Papers (45)  |  Patents (3)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (898 KB)  

    Scenarios offer promise as a way to tame requirements analysis, but progress has been impeded by the lack of a systematic way to analyze, generate, and validate them. The authors propose such a method and apply it to a simple PBX system. Their method has a formal mathematical base, generates precise scenarios, accommodates change, and keeps users involved in the process.<> View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Understanding quality in conceptual modeling

    Publication Year: 1994 , Page(s): 42 - 49
    Cited by:  Papers (40)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1465 KB)  

    With the increasing focus on early development as a major factor in determining overall quality, many researchers are trying to define what makes a good conceptual model. However, existing frameworks often do little more than list desirable properties. The authors examine attempts to define quality as it relates to conceptual models and propose their own framework, which includes a systematic approach to identifying quality-improvement goals and the means to achieve them. The framework has two unique features: it distinguishes between goals and means by separating what you are trying to achieve in conceptual modeling from how to achieve it (it has been made so that the goals are more realistic by introducing the notion of feasibility); and it is closely linked to linguistic concepts because modeling is essentially making statements in some language.<> View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Cleanroom process model

    Publication Year: 1994 , Page(s): 50 - 58
    Cited by:  Papers (27)  |  Patents (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1379 KB)  

    Cleanroom software engineering is a team-oriented process that makes development more manageable and predictable because it is done under statistical quality control. The philosophy behind cleanroom software engineering is to avoid dependence on costly defect-removal processes by writing code increments right the first time and verifying their correctness before testing. Its process model incorporates the statistical quality certification of code increments as they accumulate into a system.<> View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Managing code inspection information

    Publication Year: 1994 , Page(s): 59 - 69
    Cited by:  Papers (12)  |  Patents (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (2797 KB)  

    Inspection data is difficult to gather and interpret. At AT&T Bell Laboratories, the authors have defined nine key metrics that software project managers can use to plan, monitor, and improve inspections. Graphs of these metrics expose problems early and can help managers evaluate the inspection process itself. The nine metrics are: total noncomment lines of source code inspected in thousands (KLOC); average lines of code inspected; average preparation rate; average inspection rate; average effort per KLOC; average effort per fault detected; average faults detected per KLOC; percentage of reinspections; defect-removal efficiency.<> View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Technology transfer at Motorola

    Publication Year: 1994 , Page(s): 70 - 76
    Cited by:  Papers (3)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1182 KB)  

    While developing a formal software-review process, a working group at Motorola devised a technology-transfer model that is built on process packages, each one targeted to a different user group. Their model allows for tailoring, makes training and consulting widely available, and relies on champions. The approach helps development organizations focus on the technology they really need, devise solutions, and transfer those solutions to development teams. We report on experiences using this approach in the last five years (1989-94) and the lessons learnt.<> View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Modeling control in rule-based systems

    Publication Year: 1994 , Page(s): 77 - 81
    Cited by:  Papers (1)  |  Patents (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (583 KB)  

    The Comex modeling tool (control knowledge modeling and execution tool) focuses on modeling a problem-solving strategy and representing control knowledge, the knowledge of how to select among several problem-solving actions. In addition, Comex has facilities that let you execute early versions of the model to simulate the intended system's behavior and continuously execute the evolving model, until it becomes the real system. Comex addresses the rule-based paradigm's biggest shortcoming by adding control structures to executable models. Beginning with the specification phase, you can simulate a system's behavior, then map tasks to a rule base. The result is a structured, rule-based system built according to accepted software-engineering principles.<> View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Ergonomic standards go beyond hardware

    Publication Year: 1994 , Page(s): 82 - 84
    Cited by:  Papers (3)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (421 KB)  

    European concerns about ergonomics, which are closely linked to worker health and safety have already expanded to a directive that affects user-interface design. Now the European Community is debating whether or not the directive should be tied to a standard, ISO 9241. As ISO 9000 has demonstrated, this is not just a concern for European developers. US developers are also finding that ISO standards gate their entry into the global market. The author reports on the status of this decision. Although conformance issues are still being hotly debated, ISO 9241 may be laying the foundation for more usability standards. Software companies may soon have a new ISO standard to be concerned with.<> View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Fast, cheap requirements prototype, or else!

    Publication Year: 1994 , Page(s): 85 - 87
    Cited by:  Papers (6)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (503 KB)  

    Managing requirements modeling and prototyping is risky. If things go awry, projects can spiral out of control. Over the years, with the help of colleagues from industry and academia, the author has identified a requirements modeling and prototyping process that is fast, powerful, cost-effective, sane, and objective. The main lesson learnt is that throwaway prototyping (sometimes called exploratory prototyping) is always cost-effective and always improves specifications. The process has nine steps: elicit initial requirements; model requirements; identify constraints; prioritize initial requirements; design; evaluate designs; specification; interactive prototyping; and requirements validation.<> View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Process assessment with a project focus

    Publication Year: 1994 , Page(s): 89 - 91
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (340 KB)  

    The author compares three process assessment techniques that measure improvement against the Software Engineering Institute's capability maturity model (CMM), particularly the Computer Science Corporation's software process audit method. The Software Engineering Institute has developed two approaches to determine an organization's process maturity: software process assessments (SPA) and software capability evaluations (SCA), both of which use the SEI's CMM as a yardstick. Computer Science Corporation's software process audit method addresses the major limitations of the SPA, ie. SPAs occur too infrequently to track progress; SPA results are reported at the organization, not project level; and SPAs direct process improvement at the organizational level. The process-audit approach at CSC focuses on projects, specifically their conformance to the organization's defined process. As such, a process audit fits between a SPA and an SCE.<> View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.

Aims & Scope

IEEE Software's mission is to build the community of leading and future software practitioners. The magazine delivers reliable, useful, leading-edge software development information to keep engineers and managers abreast of rapid technology change

Full Aims & Scope

Meet Our Editors

Editor-in-Chief
Diomidis Spinellis
Athens University of Economics and Business
28is Oktovriou 76
Athina 104 33, Greece
dds@computer.org