http://tc.eserver.org/dir/Specifications A listing of the most recently indexed works about Specifications in the field of technical communication. en-us Copyright (c) 2005-08 by the EServer. All rights reserved. tclib-editorial@eserver.org (TC Library Editorial Board) webmaster@eserver.org (Geoffrey Sauer) http://tc.eserver.org/images/newlogo.gif http://tc.eserver.org/dir/Specifications http://tc.eserver.org/35178.html http://tc.eserver.org/35178.html The role of the interaction designer is to specify the interface’s behaviors and elements, so that engineers know what to build and how the product should operate. This documentation is commonly known as a UI specification or UI spec. There are several applications for authoring a UI spec, with wikis being a relatively new tool. However, designers should be aware of a wiki’s benefits and drawbacks for documentation, since UI specs uniquely reflect a project and its context. The documentation needs are often based on the size of the project, launch date, team dynamics, audience, technology, and the product development process. The development process usually plays a major role in how teams interact and how work is completed or delivered, thus, there is a direct relationship between the UI spec and the process the team is using. http://tc.eserver.org/35179.html http://tc.eserver.org/35179.html User interface (UI) patterns have the potential to make software development more efficient. The prospect of such efficiency gains has led to interest in user interface (UI) patterns by individuals and organizations looking for ways to increase quality while at the same time reducing the costs associated with software development. http://tc.eserver.org/35167.html http://tc.eserver.org/35167.html If you’re working with the latest technology, there may not be any user reference material at all; the only documentation available is the specification. In such a case, learning to read the spec is a necessity, not a luxury. http://tc.eserver.org/34496.html http://tc.eserver.org/34496.html Test-driven development or TDD is a widely accepted practice used by agile software development teams of many flavors – not only Extreme Programming teams. For each small bit of functionality they code, programmers first write unit tests, then they write the code that makes those unit tests pass. TDD is seen as a design tool, since it forces the programmer to think about many aspects of each feature before coding. http://tc.eserver.org/34467.html http://tc.eserver.org/34467.html Requirements gathering is all about aiming at the right target. It doesn't matter how accurate you are, if you aim at the wrong target, you miss. http://tc.eserver.org/34276.html http://tc.eserver.org/34276.html This article describes several characteristics of high quality software requirement statements and specifications. We will examine some less-than-perfect requirements from these perspectives and take a stab at rewriting them. I’ve also included some general tips on how to write good requirements. You might want to evaluate your own project’s requirements against these quality criteria. http://tc.eserver.org/34277.html http://tc.eserver.org/34277.html Every project has requirements. It doesn't matter if it's building hardware solutions, developing software solutions, installing networks, protecting data, or training users. For the project to be a success, knowing what the requirements are is an absolute must. Requirements exist for virtually any components of a project or task. For example, a project may require specific methods, expertise levels of personnel, or the format of deliverables. This whitepaper will discuss the various kinds of information technology requirements, their importance, the different requirement types, the concept of requirements engineering, and the process for gathering requirements. http://tc.eserver.org/33952.html http://tc.eserver.org/33952.html When it comes to modern theater, stage directions—the descriptive text that appears within brackets in a script—are an important piece of the puzzle. They speak for the playwright when he is not there. They provide details about how the playwright has imagined the environment and atmosphere. They describe critical physical aspects of the characters and settings. Stage directions can also be critical in dictating the intended tempo and rhythm of the piece. Whether they establish a production’s overall tone or elucidate particular actions of characters, stage directions help tell the complete story that is in the playwright’s mind. Stage directions accomplish all of this, using a simple convention that structurally separates them from the actual story. http://tc.eserver.org/33667.html http://tc.eserver.org/33667.html 'The Art of the Functional Spec' is a forum for those of us responsible for writing functional specs. We'll discuss the basics of functional spec writing, offer tips, provide examples and respond to your feedback and questions. http://tc.eserver.org/29762.html http://tc.eserver.org/29762.html Creating any system of sufficient complexity requires a diverse team and a dizzying amount of documentation. While these documents do a great job of conveying components of the system, they do not provide an integrated view. This is because each covers different aspects of the system, written by a different author for a different audience. This paper proposes that project teams should create a user experience specification, a document that shows what the system looks like, how it behaves, and how it works. This specification needs to describe the system for all team members, at a useful level of detail, in a form that encourages team members to read it and inviting enough to get them to participate in the design, as well as allow developers to build from. http://tc.eserver.org/27764.html http://tc.eserver.org/27764.html What are pitfalls that companies should avoid when specifying Web applications for internal or external development? http://tc.eserver.org/27761.html http://tc.eserver.org/27761.html In general terms, the functional specification states what the proposed system is to do, whereas design is how the system is to be constructed to meet the functional specification. However in writing it, some consideration of design issues must take place, to ensure a realistic system is specified. http://tc.eserver.org/27763.html http://tc.eserver.org/27763.html An outline/template for a project's functional specification. http://tc.eserver.org/27762.html http://tc.eserver.org/27762.html A functional specification can substantially simplify and streamline the process of application development. Intended to describe how a piece of software works, it provides a ready reference for software developers andaligns large and disparate development teams to a single goal. In the process, it provides technical clarity on how the different components of aparticular applications are to be designed, implemented and integrated witheach other, and (if used correctly) significantly reduces the time and costcomponent of any development exercise. http://tc.eserver.org/27757.html http://tc.eserver.org/27757.html A functional specification (or sometimes functional specifications) is a formal document used to describe in detail for software developers a product's intended capabilities, appearance, and interactions with users. The functional specification is a kind of guideline and continuing reference point as the developers write the programming code. (At least one major product development group used a "Write the manual first" approach. Before the product existed, they wrote the user's guide for a word processing system, then declared that the user's guide was the functional specification. The developers were challenged to create a product that matched what the user's guide described.) Typically, the functional specification for an application program with a series of interactive windows and dialogs with a user would show the visual appearance of the user interface and describe each of the possible user input actions and the program response actions. A functional specification may also contain formal descriptions of user tasks, dependencies on other products, and usability criteria. Many companies have a guide for developers that describes what topics any product's functional specification should contain. http://tc.eserver.org/27760.html http://tc.eserver.org/27760.html The Functional Specification is created after the Software Requirements Document. It provides more detail on selected items originally described in the Software Requirements Document. Some software development organizations combine these two documents into a single document. http://tc.eserver.org/27758.html http://tc.eserver.org/27758.html When you use a spec, you give your trust and authority to a piece of paper rather than the people on your team. You codify laws. You strip your 'judges' of the ability to act on intuitive feelings. There’s no fluidity. There’s no ability to respond, change, and evolve. http://tc.eserver.org/27759.html http://tc.eserver.org/27759.html Don't write a functional specifications document. Why? Well, there's nothing functional about a functional specifications document. http://tc.eserver.org/27755.html http://tc.eserver.org/27755.html Whatever your role in a project, insist on getting the spec right before the code is written. The spec'ing process may take several iterations, so plan accordingly. http://tc.eserver.org/27756.html http://tc.eserver.org/27756.html When you design a product, inside and out, the most important thing is to nail down the user experience. What are the screens, how do they work, what do they do. Later, you worry about how to get from here to there. There's no use arguing about what programming language to use before you've decided what your product is going to do. In this series, I'm only talking about functional specifications. http://tc.eserver.org/27575.html http://tc.eserver.org/27575.html Your requirements document needs to focus on the user’s goals. They should not be marketing’s list of features 'we’ve got to have' because the competition has these features. They should not be a list of things the programmers think ought to be included 'because we can add those things for very little cost.' Feature bloat does not benefit the user. http://tc.eserver.org/27577.html http://tc.eserver.org/27577.html Your requirements will assist you in delivering a software solution that meets your users' needs. You can find all sorts of templates and formal processes for requirements of various kinds, and while they are useful, the biggest problem I've found is that most people confuse defining the need with proposing a solution. As soon as a requirements document contains any part of 'how we're solving this', you've crossed the line into presupposing that you already know what the problem is and can stop listening. http://tc.eserver.org/27446.html http://tc.eserver.org/27446.html Why won't people write specs? People claim that it's because they're saving time by skipping the spec-writing phase. They act as if spec-writing was a luxury reserved for NASA space shuttle engineers, or people who work for giant, established insurance companies. Balderdash. http://tc.eserver.org/27450.html http://tc.eserver.org/27450.html The Goddard Space Flight Center's (GSFC) Software Assurance Technology Center (SATC) has developed an early life cycle tool for assessing requirements that are specified in natural language. The Automated Requirements Measurement (ARM) tool was used to analyze more than 50 NASA System/Software Requirements Specification (SRS) documents. ARM reports were used to focus human analysis on specific aspects of the documentation practices exhibited by these documents. Several significant weaknesses were identified. This paper identifies the underlying problems that produce these deficiencies and recommends methods that can be used to prevent such problems. http://tc.eserver.org/27447.html http://tc.eserver.org/27447.html For technical writers who haven't had the experience of designing software requirements specifications (SRSs, also known as software functional specifications or system specifications) templates or even writing SRSs, they might assume that being given the opportunity to do so is either a reward or punishment for something they did (or failed to do) on a previous project. Actually, SRSs are ideal projects for technical writers to be involved with because they lay out the foundation for the development of a new product and for the types of user documentation and media that will be required later in the project development life cycle. It also doesn't hurt that you'd be playing a visible role in contributing to the success of the project. http://tc.eserver.org/27448.html http://tc.eserver.org/27448.html Technical specifications are improved in several ways with one easy procedure - writing them in the present tense. That is, rather than trying to specify constraints on a product that does not yet exist, describe the product as though it already existed. http://tc.eserver.org/27247.html http://tc.eserver.org/27247.html Errors in requirements specifications translate into poor designs, code that does the wrong thing, and unhappy customers. Requirements documentation should be inspected early and often. Anything you can do to prevent requirements errors from propagating downstream will save you time and money. Karl Wiegers shows you how. http://tc.eserver.org/24318.html http://tc.eserver.org/24318.html Much has been said and written about Object-Oriented Programming in the past few years, some of it even worthwhile. While not the panacea on which we've all waited, OOP is, however, changing not only our concept of software design and development, but is subtly re-shaping the way in which we see and know the world. For technical communicators, this epistemological change will radically affect not only the way we craft software specifications, but will permanently re-shape our worldview. http://tc.eserver.org/23984.html http://tc.eserver.org/23984.html Developing a new product or service is tricky. When everything goes well, the product can redefine a market or even create an entirely new one, to the benefit of its manufacturer and its consumers. When the product doesn't click with its audience, though, the costs—development, employee, manufacturing—can be staggering. How do you ensure that your new product doesn't flop? One effective method is to conduct a requirements definition phase before developing a new product. http://tc.eserver.org/22516.html http://tc.eserver.org/22516.html A collection of dozens of online resources for writers of standards and specifications. http://tc.eserver.org/20234.html http://tc.eserver.org/20234.html Although they appear maddeningly incomprehensible at first, W3C specifications are actually great sources of information, once you understand their secrets. Learn how to read the specs. http://tc.eserver.org/19648.html http://tc.eserver.org/19648.html Functional specifications (functional specs), in the end, are the blueprint for how you want a particular web project or application to look and work. It details what the finished product will do, how a user will interact with it, and what it will look like. By creating a blueprint of the product first, time and productivity are saved during the development stage because the programmers can program instead of also working out the logic of the user-experience. It will also enable you to manage the expectations of your clients or management, as they will know exactly what to expect. http://tc.eserver.org/15079.html http://tc.eserver.org/15079.html Standards related to usability can be categorised as primarily concerned with: the use of the product (effectiveness, efficiency and satisfaction in a particular context of use); the user interface and interaction; the process used to develop the product; the capability of an organisation to apply user centred design http://tc.eserver.org/14709.html http://tc.eserver.org/14709.html The authors emphasize the importance of conducting thorough research on business goals, branding goals, user needs, and technical resources before Web designers undertake a redesign. The article also offers suggestions about how to define, develop, and communicate a client's brand.