Ho alcune domande sulla scrittura di una specifica e sono:
Quando scriviamo una specifica software, sotto l'argomento "Definizione dei requisiti utente", dobbiamo specificare solo "Funzioni" e "Vincoli"?
"Interfaccia utente" rientra in "funzioni" o "vincoli"?
Quali sono le principali aree chiave (requisiti) in cui è possibile suddividere un software (ad es. UI)?
Sebbene non sia un grande fan nel raccogliere in anticipo i requisiti tutti (poiché sono soggetti a così tanti cambiamenti nel corso di un progetto non banale), se si stanno scrivendo i documenti dei requisiti , il modello delle specifiche dei requisiti Volere è un'ottima guida.
Sebbene possa essere eccessivo per alcuni progetti, fornisce una lista di controllo su cose a cui pensare, anche se è solo per controllare mentalmente l'elenco che non è necessario quell'elemento per questo requisito.
Ecco un link per ulteriori informazioni sul modello:
Il modello stesso (e il libro Padroneggiare il processo dei requisiti - che in realtà è leggermente meno costoso del modello e contiene il testo completo del modello) contiene molte informazioni, esempi e consigli all'interno delle varie sezioni su cosa dovrebbe andare in ogni sezione.
Ecco un riassunto delle sezioni in esso contenute (citato dal link precedente):
The Purpose of the Project
The Stakeholders
Mandated Constraints
Naming Conventions and Definitions
Relevant Facts and Assumptions
The Scope of the Work
Business Data Model and Data Dictionary
The Scope of the Product
Functional and Data Requirements
Look and Feel Requirements
Usability and Humanity Requirements
Performance Requirements
Operational and Environmental Requirements
Maintainability and Support Requirements
Security Requirements
Cultural and Political Requirements
Legal Requirements
Open Issues
Off-the-Shelf Solutions
New Problems
Tasks
Migration to the New Product
Risks
Costs
User Documentation and Training
Waiting Room
Ideas for Solutions
Raccomando di leggere Joel sul software. Non sono sicuro che risponda alle tue domande specifiche, ma ha una eccellente panoramica di cosa significa scrivere le specifiche funzionali :
The most important function of a spec is to design the program. Even if you are working on code all by yourself, and you write a spec solely for your own benefit, the act of writing the spec — describing how the program works in minute detail — will force you to actually design the program...
...when you design your product in a human language, it only takes a few minutes to try thinking about several possibilities, revising, and improving your design. Nobody feels bad when they delete a paragraph in a word processor. But when you design your product in a programming language, it takes weeks to do iterative designs. What’s worse, a programmer who’s just spend 2 weeks writing some code is going to be quite attached to that code, no matter how wrong it is...
...When you write a spec, you only have to communicate how the program is supposed to work once. Everybody on the team can just read the spec. The QA people read it so that they know how the program is supposed to work and they know what to test for. The marketing people use it to write their vague vaporware white papers to throw up on the web site about products that haven’t been created yet. The business development people misread it to spin weird fantasies about how the product will cure baldness and warts and stuff, but it gets investors, so that’s OK. The developers read it so that they know what code to write. The customers read it to make sure the developers are building a product that they would want to pay for. The technical writers read it and write a nice manual...
When you don’t have a spec, all this communication still happens, because it has to, but it happens ad hoc. The QA people fool around with the program willy-nilly, and when something looks odd, they go and interrupt the programmers yet again to ask them another stupid question about how the thing is supposed to work...
without a detailed spec, it’s impossible to make a schedule... In too many programming organizations, every time there’s a design debate, nobody ever manages to make a decision, usually for political reasons. So the programmers only work on uncontroversial stuff. As time goes on, all the hard decisions are pushed to the end... Writing a spec is a great way to nail down all those irritating design decisions, large and small, that get covered up if you don’t have a spec...
When we write a software specification, under the topic "User requirements definition" we have to specify the "Functions" and "Constraints" only ?
Un requisito è una combinazione di due cose ...
Does "User Interface" fall into "functions" or "constraints" ?
Direi che "Interfaccia utente" sarebbe una categoria di requisiti che hai identificato nella tua ultima domanda.
What are the major key areas (requirements) a software can be broken into (e.g. UI ) ?
Dipende dal software. È possibile raggruppare i requisiti in base a parti del sistema o raggrupparli in base al caso d'uso o ai requisiti aziendali che le funzioni stanno rispettando.
Ovviamente tutto questo è secondario rispetto al tuo obiettivo reale che è quello di determinare una descrizione chiara, non ambigua e testabile del sistema software.
Il requisito principale per un requisito è che sia verificabile. Se non riesci a capire come testare un requisito, le probabilità sono che non sarà implementato come previsto dallo scrittore.
Non ho mai visto un documento di requisiti limitato a funzioni e vincoli solo, ma posso vedere un certo valore nell'avere una struttura come questa - costringe lo scrittore a categorizzare i requisiti in "cose che il software deve fare", e "regole che il software deve seguire".
Penso che un'interfaccia utente abbia requisiti in entrambe le categorie
Vincoli:
Funzioni:
Start , il software deve stabilire una connessione TCP / IP a WOPR " Leggi altre domande sui tag requirements documentation