A directory of resources inthe field of technical communication.

Specifications

26-30 of 30 found. Page 2 of 2.

About this Site | Advanced Search | Localization | Site Maps
 

« PREVIOUS PAGE 1 2

A functional specification is the set of documentation that describes the requested behavior of an engineering system. The documentation typically describes what is needed by the system user as well as requested properties of inputs and outputs.

 

26.
#34496

Using Customer Tests to Drive Development

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.

Agile Journal (2009). Articles>User Centered Design>Agile>Functional Specifications

27.
#35178

Using Wikis to Document UI Specifications

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.

Gremett, Peter. Boxes and Arrows (2009). Articles>User Experience>Interaction Design>Functional Specifications

28.
#34276

Writing Quality Requirements

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.

Wiegers, Karl E. Process Impact (2007). Articles>Project Management>Business Communication>Specifications

29.
#27447

Writing Software Requirements Specifications

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.

Le Vie, Donald S., Jr. TECHWR-L (2000). Articles>Writing>Specifications>Technical Writing

30.
#27448

Writing Technical Specifications in the Present

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.

Kendall, Matthew. Ionocom (2005). Articles>Writing>Specifications>Grammar

 
« PREVIOUS PAGE 

 

Follow us on: TwitterFacebookRSSPost about us on: TwitterFacebookDeliciousRSSStumbleUpon