仕様書をExcelで書くんじゃねぇ:アルファルファモザイク
>>3 ていうかエクセルで印刷するのはキツイ。txtのほうがまし。 平均１０ページ×３０シート×５０ファイルなんて泣きたくなるぞ。 そのうえ印刷するとあちこちのセルが欠けるもんだから、徹夜で直したことがある。 個人の資料ぐらいならいいけど、人に渡すつもりならホント止めてほしい。
>>3 ていうかエクセルで印刷するのはキツイ。txtのほうがまし。 平均１０ページ×３０シート×５０ファイルなんて泣きたくなるぞ。 そのうえ印刷するとあちこちのセルが欠けるもんだから、徹夜で直したことがある。 個人の資料ぐらいならいいけど、人に渡すつもりならホント止めてほしい。
・要件定義 成果物は「経営者が参画する要求品質の確保」に記述されている 表4．3「役割分担と成果物例」にならい分類・表示している。 方向性と計画についてはこちら
ゲームの仕様書を初めて作成する人のための足掛かりのスライド ▼以下のスライドを一つにまとめました ・ゲームの仕様書を書こう１ 仕様書作成の分業とリストの作成 https://www.slideshare.net/ChizuruSugimoto/ss-173331109 ・ゲームの仕様書を書こう２ 仕様書に記載する機能内容 https://www.slideshare.net/ChizuruSugimoto/ss-173332578 ・ゲームの仕様書を書こう３ 仕様書に記載するデータと画面 https://www.slideshare.net/ChizuruSugimoto/ss-173333150 ・ゲームの仕様書を書こう４ 仕様書作成で楽をするconfluenceの活用 https://www.slideshare.net/ChizuruSugimoto/confluence-17333
【データ基盤チーム ブログリレー 3日目】 こんにちは、エンジニアリンググループの石塚です。 趣味は筋トレです。好きなトレーニングはレッグカールです。今年2023年の1月に第一子が爆誕し、毎日子供の笑顔に癒されております。一方であまり言い訳にはしたくはないですが、事実自分自身の自由に使える時間は少なくなったなと感じております。そんな中でもトレーニングの時間は作りたいので、24時間ジムに契約して妻と娘が寝ている早朝の時間にウホウホトレーニングをしている今日この頃であります。時間のありがたみをとても感じるようになりました。 これは仕事でも同様かと思います。有限な時間の中でタスクを取捨選択して価値ある成果を上げていく事が仕事では求められます。ドキュメンテーションはその価値ある成果につながる時間を増やす一助になるかもしれません。 この記事では、ドキュメンテーションの必要性について言語化します。改め
第19回 画面遷移図作成の基本
企画書と同時に提出する画面遷移図は，Webの骨格だ。この図一つで，制作・開発効率や工期が決まるといっても過言ではない。今回と次回で，画面遷移図作成の基本と実践について見ていこう。 開発の効率化と長期運用のために 画面遷移図の果たす役割は大きい。顧客に完成予想図をイメージしてもらい，受注を獲得するための一助になる。概算見積書を作成するための資料にもなる。そして，実装機能やデータベース設計を固めるためのタタキ台にもなる。企画書と共に提出すれば終わりというわけではなく，モックアップやプロトタイプ開発にも利用できる。顧客との間で意識や記憶にズレが生じた場合の確認資料としても重宝する。 受注が確定的になると，顧客の要求を入れながら，何度も修正を重ねていく。画面遷移図の段階で調整に時間をかけて完全な合意を得ておけば，開発はスムーズに進む。段取り八分が何より肝心だ。データベース設計のような根幹の部分に変
本ドキュメントは、Weblogs At Harvard Law （ハーバード大学法学大学院のウェブログ）で公開されている 『RSS 2.0 Specification』 を futomi が日本語化したものです。みなさまの理解に役立てれば幸いです。なお、緑色で記載された文章は、futomi が注釈として加筆したものです。また、一部、直訳ではなく、意訳した部分がございます。原文と表現が異なることがございますので、ご了承ください。 注意: この日本語訳は、futomi が理解を深めるために、自分なりに日本語化したものです。本日本語訳には、翻訳上の誤りがある可能性があります。したがって、内容について一切保証をするものではありません。正確さを求める場合には、必ず原文を参照してください。当方は、この文書によって利用者が被るいかなる損害の責任を負いません。 もし誤りなどを見つけたら、こちらからご連絡い
The OAuth 2.0 Protocol draft-ietf-oauth-v2-10 Abstract これはOAuth 2.0プロトコルの仕様書である. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is
「地方公共団体における情報システムセキュリティ要求仕様モデルプラン（Webアプリケーション）」を一般公開しました - 財団法人 地方自治情報センター（LASDEC）
現在位置： ホーム > 情報セキュリティ 対策支援 > 自治体セキュリティ支援室からのお知らせ > 「地方公共団体における情報システムセキュリティ要求仕様モデルプラン（Webアプリケーション）」を一般公開しました 背景 情報システムは住民向けのサービス基盤として欠かせない存在ですが、情報システムを安全に利用する上で避けては通れない問題があります。それが「脆弱性」に関する問題です。 脆弱性とは情報セキュリティ上の弱点のことであり、脆弱性の問題を放置すると、情報の流出や、ホームページ等コンテンツの改ざん、サービスの停止などの問題を引き起こす可能性があります。一見すると安定して動作しているように見えていても脆弱性が内在することもあり、情報システムの調達・構築・運用にあたってこの対処をあらかじめ決めておくことは安定的な運用に欠かせないことです。 特に近年ではWebアプリケーションの脆弱性
XHTML™ 1.0: 拡張可能ハイパーテキストマークアップ言語 この文書は、W3Cにより作成されW3C勧告として公開されている "XHTML" 1.0: The Extensible HyperText Markup Language " (http://www.w3.org/TR/2000/REC-xhtml1-20000126/) を、どら猫本舗が翻訳したものです。 最新版の文書は http://www.w3.org/TR/xhtml1/ にあります。 正式なワーキングドラフトはW3Cサイトにある英語版です。この日本語版は参考にすぎません。 この文書には翻訳上の誤りがあるかもしれません。どら猫本舗は翻訳の正確性を保証しません。あくまでご自身の責任でご利用ください。 お気付きの点がありましたらどら猫本舗までお知らせください。 XHTML™ 1.0: 拡張可能ハイパーテキストマークアップ
時々組織の内外で盛り上がるネタの一つに「設計書は必要なのか」談義がある。今回も後輩の一人から設計書不要論がぶつけられてきたので、現時点での個人的見解をまとめておくもの。個人的には、ソフトウェアの設計書は必須でもないし、開発戦略を練る段階で作成するかどうかを決めればいいと思っている。 議論の前提：仕様書と設計書 議論を簡単にするために、まず「仕様書」と「設計書」という言葉を再定義しておきたい。今回の整理は以下としている。 仕様書 … 開発者とユーザー(仕様決定者)が、ソフトウェアの振る舞いや動きに関してコミュニケーションするために必要な文書類のこと。 設計書 … 開発者どうしがソフトウェアを作成するにあたっての、構造や仕様についてコミュニケーションするために必要な文書類のこと。 要は今回議論しようとしている「設計書」は、ユーザー(仕様決定者)とは無関係なものであるという前提である。また、ここ
以前からテキストベースで仕様書(PDF)などを管理したいと思っていたのですが、ようやくその環境が整い、一度実際に運用してみてかなりいい感じだったので紹介したいと思います。 基本テキストは AsciiDoc で記述する UML は PlantUML で記述する フローチャートとかは必要に応じて mermaid.js も使う つまり基本テキストで表現・管理できるものはテキストで書く 成果物は PDF形式。目次(Table of Contents) はつける。 動作確認環境 macOS Sierra 10.12.3 ruby 2.3.1 Asciidoctor 1.5.5 Asciidoctor PDF 1.5.0.alpha.14 Asciidoctor Diagram 1.5.4 mermaid 7.0.0 AsciiDoc とは AsciiDoc Home Page 軽量マークアップ言語の
第35回 画面設計書はどう作られるべきか
Webサイトを構築する場合，通常は「設計書」を作成します。サイト全体の設計書であったり，ページ単体の設計書であったりするわけですが，今回は後者である「画面設計書」について考えてみましょう。 画面設計書を読むのは誰か Webサイトの構築では，対象ユーザーをできる限り具体的に決めてから開発を進めていきます。同様に，画面設計書にも「対象読者」を見定める必要があります。結論から言えば，かなり属性の異なる二種類の読者が存在します。 まず，発注者である「クライアント」です。クライアントは，技術的な難易度ではなく，自分たちのビジネス要件を満たすものが作られるかどうかを確認するために画面設計書を読みます。開発（プロジェクト）のゴールや，プロジェクトのメリット/デメリット，リリース後の顧客満足の予想などを，その設計書から読み取ろうとします。したがって，できる限り具体的なイメージが伝わるものが要求されます。
HTML Standard 日本語訳
4.8.4 画像4.8.4.1 導入4.8.4.1.1 アダプティブ画像4.8.4.2 source、imgおよびlink 要素の共通属性4.8.4.2.1 srcset共通属性4.8.4.2.2 size属性4.8.4.3 Processing model4.8.4.3.1 When to obtain images4.8.4.3.2 Reacting to DOM mutations4.8.4.3.3 The list of available images4.8.4.3.4 Decoding images4.8.4.3.5 Updating the image data4.8.4.3.6 Preparing an image for presentation4.8.4.3.7 Selecting an image source4.8.4.3.8 Creating a source s
失敗例その1 「要件定義が終わらない」 ユーザーから要求を聞き出し、システム要件に落とし込んでいくのが要件定義だ。要件定義が終わらないかぎり基本設計に移れない。しかし、要件定義がいつになっても終わらない。その理由として、ユーザーからうまく要求を引き出せないことがある。そもそも今回のシステム開発でユーザーが具体的に何をやりたかったか、どんなものをIT化すればよいのかがはっきりしない。3カ月と予定されていた要件定義工程はすでに１カ月オーバーしてしまっている、しかもユーザーが満足するような要件定義書がいまだにできていない。 失敗例その2 「設計工程の無駄」 オープン系の開発でウォーターフォール開発を行っている。設計工程は、基本設計、詳細設計に分かれている。基本設計では、要件定義に基づき、主に画面などユーザーがシステムを利用するうえで意識する部分を設計し、詳細設計では、それをプログラムにつなげるた
以前、「SWFファイルフォーマットとライセンス 」で、SWFのファイルフォーマット仕様書の利用許諾に、SWFファイルを読み込むプログラムを作成してはいけないと書かれていることを紹介しました。 今日、Adobeから「Adobe and Industry Leaders Establish Open Screen Project」というプレスリリースがあり、その中に以下の一文がありました。 - Removing restrictions on use of the SWF and FLV/F4V specifications ということで、SWFの仕様書を制限無しに読むことが可能になったようです。 他にも、Flash Playerの移植レイヤが公開され、Flash Playerを移植してもライセンス料が取られなくなる等が発表されているようです。私もまだ流し読みしかしていないのですが、とても大き
最近のシステム構築では仕様書をきちんと記述しないで、いきなりツールを使ってプログラムを作成することも多いようだ。否定する気はないが、駆け出しのころはしっかり自分の手で仕様書を書いた方がいい。 前回は、SEを目指している皆さんに向けて、仕事に取り組む姿勢の観点からアドバイスを書いた。今回は、SEに求められるより具体的な知識やスキルの向上に役立つ話を書いてみたい。 SEとして必要な知識やスキルは非常に広範にわたる。経験を積み、上級SEになってくればより経営的な知識が求められるが、最初のころは、システム構築に必要な知識やスキルが特に重要になる。今回は、システム構築における基礎的なスキルの開発方法を紹介しよう。 仕様書を書くこと 最近のシステム構築では、仕様書をきちんと記述しないで、いきなりツールを使ってプログラムを作成したり、システムを構築したりする手法が取られることも多いようだ。こういった手法
基本設計書
第1回で「業務フロー」、第2回で「機能一覧表とI/O関連図」について説明しました。今回は残りのアウトプットを取り上げて、基本設計フェーズのドキュメント標準を完了させることにします。「DUNGEON」の標準で定義されている基本設計工程のアウトプットは、表1の通りです。
意図が伝わる設計書作成の心得【第1回】：行きすぎた技術志向
設計書の書き方には絶対的な公式があるわけではない。必然的に，設計者の「経験」と「力量」に依存する部分が多くなる。標準の設計フォームや設計書作成ガイドラインを用意することで，このような事態を避けようとしている開発現場は多いだろう。しかし，型通りに作った設計書が，常に目的にかなった“正しいもの”であるとは限らない。 一般によく言われることだが，設計書の書き方には「正解」や「こうしなければならない」という絶対的な公式があるわけではない。必然的に，設計者の「経験」と「力量」に依存する部分が多くなり，完成した設計書の内容と質は設計者ごとに大きく異なる――といった結果に陥りやすい。 もちろん，標準の設計フォーム（ひな型）や設計書作成ガイドラインを用意することで，このような事態を避けようとしている開発現場は多いだろう。しかし，型通りに作った設計書が，常に目的にかなった“正しいもの”であるとは限らない。一
医学書専門 校正・校閲 校正舎－校正記号－
この「印刷校正記号一覧」は、JIS Z 8208：2007（印刷校正記号）に示されている記号と使い方（横組）を再編集したものです。縦組についてなど、詳しい内容は同規格票（日本規格協会：http://www.jsa.or.jp/ で入手可）をご参照ください。
要求仕様戦争（その1）
■要求仕様とは 要求仕様とは、開発するシステムに対する顧客のニーズのこと。要するに「お客さんがやりたいこと」そのもの。仕様調整で紛糾したときの決め台詞「結局アナタは何がしたいの?」の【何】に相当する。仕様トラブルの100％はこのスレ違いによる。 要求仕様について考えるために、ちょっとした質問に答えてみよう。以下のa. b. のうち、「要求仕様」を表現しているのはどちらになるだろうか? a. 身長57メートル体重550トン b. 汎用人型決戦兵器 まず a. を考えてみる。これは「何」だろうか? これは「何」かのスペックだ（しかも部分的だ）。身長・体重は分かるが、横幅や厚み、姿かたち、素材 etc... は分からない。これは受注側が「○○はどうするの?」といちいち問い合わせる必要がある。当然、聞くのを忘れたスペックは製造者の「思い」で作られるリスクを負う。 次に b. はどうだろう。身長・体
この文章の取り扱い この文章にはInternet communityのためのExperimental Protocolを定義し、改善のための意見と提案が寄せられています。 このプロトコルと標準化の状況については"IAB Official Protocol Standards"の最新版を参照して下さい。 この文章の配布は自由に行ってかまいません。 <訳者注:>これは原文の取り扱いです。日本語訳についてはセクション13.2 「日本語訳について」に準じます。 また、IRCプロトコルの定義はあくまで原文であることを断っておきます。 概要 最初にBBS上のユーザ間のチャットの方法として使われ初めてから4年間以上にわたって、IRCプロトコルは開発が進められています。 現在、このプロトコルはサーバ／クライアント方式で世界中のネットワークをカバーしています。そして、ネットワークの成長に伴って、プロトコルも
Using Intel® Hyper-Threading Technology| Intel® Math Kernel Library for macOS
Using Intel.com Search You can easily search the entire Intel.com site in several ways. Brand Name: Core i9 Document Number: 123456 Code Name: Emerald Rapids Special Operators: “Ice Lake”, Ice AND Lake, Ice OR Lake, Ice* Quick Links You can also try the quick links below to see results for most popular searches. Product Information Support Drivers & Software
日本語組版処理の要件（日本語版）
0.1 このドキュメントの目的 書記システムは，言語，文字と並び，文化を構成する重要な要素である．それぞれの文化集団には独自の言語，文字，書記システムがある．個々の書記システムをサイバースペースに移転することは，文化的資産の継承という意味で，情報通信技術にとって非常に重要な責務といえよう． この責務を実現するための基礎的な作業として，このドキュメントでは，日本語という書記システムにおける組版上の問題点をまとめた．具体的な解決策を提示することではなく要望事項の説明をすることにした．それは，実装レベルの問題を考える前提条件をまず明確にすることが重要であると考えたからある． 0.2 このドキュメントの作成方法 このドキュメントの作成は，W3C Japanese Layout Task Forceが行った．このタスクフォースは，次のようなメンバーで構成され，ユーザーコミュニティーからの要望と専門家
Bridge Word
This shop will be powered by Are you the store owner? Log in here
英語ドキュメントが読みやすくなるテクニックで仕様書を読んでみる
たとえ国内で仕事をしていても、IT系の最新情報やドキュメントはほとんど英語のため、英語をすらすら読めるようになったほうがなにかと捗ります。そこで、翔泳社から刊行した『現場で困らない！ ITエンジニアのための英語リーディング』よりテクニックを四つ紹介。さらにAPIリファレンスや仕様書などを実際に読んでいきましょう。 重要なテクニックはたった四つ 本書『現場で困らない！ ITエンジニアのための英語リーディング』で紹介される、英語をすらすら読めるようになるテクニックはたった四つしかありません（もちろん英語の基礎やある程度の語彙は前提となります）。 一つ目は「英語の語順で理解する」。学生時代の名残からか、英語を読むときにどうしても日本語のように文章の後ろから前へ戻るように訳してしまいがちです。しかし、これはNG。英語の語順のまま意味を理解していくほうが素早く読めます。 二つ目は「スラッシュ・リーデ
【注意】 この文書は、2008 年 12 月 11 日付の W3C 勧告「WCAG 2.0」 (原文は英語)を、情報通信アクセス協議会の「ウェブアクセシビリティ基盤委員会 (WAIC)」が翻訳と修正をおこなって公開しているものです。この文書の正式版は、あくまで W3C のサイト内にある英語版であり、この文書には翻訳上の間違い、あるいは不適切な表現が含まれている可能性がありますのでご注意ください。 【注意】この文書にはより新しいバージョンが存在します: Web Content Accessibility Guidelines (WCAG) 2.1 W3C 勧告 2008 年 12 月 11 日このバージョン: http://www.w3.org/TR/2008/REC-WCAG20-20081211/ 最新バージョン:http://www.w3.org/TR/WCAG20/前のバージョン:
第2回 簡潔なコーディングのために （2017/7/26） ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている 第1回 Visual Studio Codeデバッグの基礎知識 （2017/7/21） Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう 第1回 明瞭なコーディングのために （2017/7/19） C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える Presentation Translator （2017/7/18） Presentation TranslatorはPowerPoint用のアドイン。プレゼンテー
「仕様書」とは、Webサービスやアプリなどのプロダクトを作るうえで満たすべき要件をまとめた開発者への説明書のこと。「どこにどのような機能を持たせるのか」「どこからどのように遷移させるのか」といったプロダクトのあるべき姿を記載します。 開発の要となる重要な要素だけに、作成に苦労している企画者やディレクターの方も多いかもしれません。 特に海外で開発する場合は言語や距離の問題で依頼者と開発者の間の意思疎通が難しく、仕様書の重要性がさらに高まるでしょう。しかし、これは仕様書さえしっかりしていれば国内であれ海外であれ難なく開発を行えるということでもあります。 そこで本記事では、国内外問わず幅広く案件を担当し、自社サービスの開発に携わった筆者が、重要視している仕様書作成の注意点をお伝えていきます。 ➡︎【資料ダウンロード】アプリ開発の企画～発注の教科書＜2023年最新版＞ 仕様書とは？ Webサービス
Latex + GitLab + Jenkinsで全自動仕様書作成システムを作った. - 「不自由な自由」を持て余して
経緯 私の務めている会社ではMicrosoftさんの製品が主に使われています. 私はMicrosoft Wordを使うとあまりの使いづらさに集中力が切れて仕事の能率が著しく低下するのですが,そんな私に上司はある日「要件定義書書いて.」という言葉を投げかけてきました.要件定義書？また作業が滞る日々が続くと思ったので先手を打って起きました. 曰く,「PDF形式でも宜しいですか？」と. 上司は怪訝な顔をしながらも承諾してくださいました.これで,私の無駄なことに全力になってしまう本能が遺憾なく発揮されるのでした. 成果物 Latexで仕様書を書いた.GitLabで成果物管理をした. GitLabとJenkinsを連動させて,Push後に自動的にBuildするシステムを作り上げた. 無駄にLatexのMakefileに詳しくなった. 手順 Ubuntu 12.04でLaTeX環境を構築する GitL
実際のスライド作成時に気をつけるべき10の鉄則とKISS
スライドの構想も、手描きのラフの作成も完了したら、ようやくPCの出番です。ラフの描き方については、バックナンバーの「スライドは『いきなりPC』で作らない――ラフの手書きから」を参照してください。 基本的にスライドはPowerPointやWord、そのほかプレゼンテーションの作成ソフトで資料を作ります。ただし、下記にあるような10個の鉄則を守って作成しましょう。 スライド作成時に注意したい10の鉄則 1スライドに1メッセージ 可能な限り説明スライドは10枚以内 こりすぎない、Simple is best! フレーズは短く、キーワードを強調 メッセージを一番うまく伝えるデザインを選択 細かいデータは別資料で補う しくみはアイコンや単純パーツの図解で示す イメージは言葉ではなく、写真や映像で 数字やトレンドに最適なグラフを選択する エグゼクティブサマリーは30秒一本勝負 プレゼンを行うものはすべ
Swaggerの概要をまとめてみた。 - Qiita
最近は API Blueprint で仕様書を書くことが多かったのですが、Swagger が世界標準になるかもしれない、ということもあり、開発の効率化を進めるためにも概要をまとめてみようと思った次第です。 Swaggerとは Swagger は RESTful APIを構築するためのオープンソースのフレームワークのことです。「Open API Initiative」という団体がRESTful APIのインターフェイスの記述をするための標準フォーマットを推進していて、その標準フォーマットがSwaggerです。Swaggerには多くの便利なツールが提供されていることもあり、多くのメリットを享受できそうです。 Swagger Spec を書いておけば自動的にドキュメント生成までしてくれ、それだけではなく、ドキュメントから実際のリクエストを投げられる優れものです。 Swaggerのツール群 ツール
Notion AIを用いて機能仕様書からテストケースを自動で作成した話 - Commune Engineer Blog
はじめに コミューンでQAをしています金丸です。 最近QA界隈でAIを用いたソフトウェア開発が注目を集めています。 www.kzsuzuki.com 多くはChatGPTを用いたものですがちょうど先月にNotion AIがリリースされたので今回Notion AIがソフトウェア開発のテスト部分に対して有用に使うことができるかについて記事を書いていきたいと思います。 結論から言うと、実用としての運用は未だ難しいがQAの補佐的な位置付けとしては十分な働きをしてくれることがわかりました。 はじめに NotionAIとは 機能仕様から同値分割・境界値分析・フローチャートを自動で作成 機能仕様の修正もNotionAIにやっていただいた 終わりに NotionAIとは NotionAIは、Notion Labs, Inc.によって開発された人工知能モデルです。個人や仕事に関するタスクの作成、整理、管理を
CSS Coding Guideline
CSS Coding Guideline 移動のお知らせ この度、CCGは移動いたしました。CSS Coding Guideline何卒よろしくお願い申し上げます。
プログラマに負担をかけない仕様書の書き方や対応についての質問です。 今後、プログラマに事細かに指示を出す必要がある仕事に自分がつきそうです。いろいろなサイトを見ましたが、意思の疎通がうまくいかず、プログラマに負担がいってしまう事例が多くあり、気を引き締めて取りかかりたいと思います。 自分も若干の言語ならばわかりますが、ほとんど無知の状態に近いです。 自信の勉強ももちろんのこと、ミーティングなども綿密に行う事が必要ですが、その他に気をつけなければならない事や注意点、プログラマから見たやりやすさなどがありましたら教えて下さい。 また、どういう状況での作業がやりやすか、などの環境についてもよければご意見を聞きたいと思います。
Joel on Software - やさしい機能仕様 - パート 1: なぜわざわざ書く必要があるのか?
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/10/2 The Joel Testを発表したとき、読者から寄せられた最大の不満の種は、仕様書を書かなければならないということだった。仕様書はデンタルフロスみたいなもので、みんな書かなきゃいけないと思ってはいるが、誰も書かない。 なぜ人々は仕様書を書きたがらないんだろう? 人々は仕様書作成フェーズを飛ばせば時間を節約できると主張している。彼らは仕様書作成がNASAのスペースシャトルのエンジニアか巨大な保険会社で働いているような人たちのための贅沢品であるかのように振舞っている。戯言だ。何よりも仕様書を書かないというのは、あなたがソフトウェアプロジェクトに持ち込む、最大かつ不必要なリスクである。それは着替えだけリュックに詰めて、その場になれば何とかなることを期待してモハーベ砂漠の横断に出発するの
詳細設計書（前半）
前回までに表1の? 7「機能設計書」の基本設計ドキュメントとして、「表紙」「I/O関連図」「画面レイアウト」「帳票レイアウト」について紹介しました。今回からは、詳細設計に関するドキュメントについて順に説明していきます。 "機能"単位での設計書 機能設計書は、機能単位でドキュメントが作成されます。例えば、「プロスペクト登録画面」と「プロスペクト一覧画面」と「プロスペクト一覧表」という3つの機能があれば、3セットの機能設計書を作ることになります。ここで注意して欲しいのは、設計書の記述はあくまでもユーザのイメージする"機能"単位で、プログラミング単位の"プロシージャ"や"クラス"ではないということです。この"機能"という概念について、図1「プロスペクト登録画面」を例に説明しましょう。 図1を見ると、「プロスペクト登録画面」という機能は、画面、イベント、BL（ビジネスロジック）などのオブジェクトか
この記事は、Mozilla Japan 翻訳部門もしくはその関連グループによりすでに翻訳済みのものを移行してきました 移行元の文書。英語版と内容が異なる場合や、MDC の他の記事と整合性のとれていない場合があります。 以下の文書では Mozilla の UI で使用する CSS ファイルの最適化についての規則を概説します。最初の節では Mozilla のスタイルシステムにおけるルール分類の要について書きます。このシステムについて理解してもらった上で、続く節では Mozilla のスタイルシステムの力を最大限に発揮するルールの書き方を説明します。 【訳注: CSS スタイルのマッチング処理に於いては、ルール集合のうち各要素に対してマッチするものがないか順に全て調べていく必要があり、単純計算では (要素数)×(ルール数) 回のマッチング処理が必要になってしまいます。如何にしてこれを効率化するの
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
超上流から攻めるIT化の事例集：要件定義 | アーカイブ | IPA 独立行政法人 情報処理推進機構
ゲームの仕様書を書こうまとめ
エンジニアリングの時間を生み出すドキュメンテーション術 - エムスリーテックブログ
RSS 2.0 Specification 日本語訳 - futomi's CGI Cafe
The OAuth 2.0 Protocol
XHTML 1.0: 拡張可能ハイパーテキストマークアップ言語
開発者向けのソフトウェア設計書は必要か？ - 勘と経験と読経
AsciiDoc と PlantUML と mermaid.js で素敵なテキストベース仕様書ライフ
「現状のソフトウェア開発は間違っていないか？」（プロセス編）
(速報)SWF SpecificationがOpenになりました : DSAS開発者の部屋
ITmedia エンタープライズ：SEの道は仕様書に始まり仕様書に終わる (1/3)
RFC1459: Internet Relay Chat Protocol (IRC)
WCAG 2.0
アプリケーション・アーキテクチャ・ガイド2.0解説 - ＠IT
仕様書とは？開発事例をもとに成功する仕様書の書き方を解説 - 株式会社モンスターラボ
http://diveintogreasemonkey.org/toc/
プログラマに負担をかけない仕様書の書き方や対応についての質問です。…
AIが「理解」するから、API仕様書のコピペでアプリができあがるローコード開発環境「Flowise」を試す【イニシャルB】
http://watcher.moe-nifty.com/memo/docs/twitterAPI50.txt
Writing Efficient CSS - MDC